Red Hat Bugzilla – Bug 998232
[abrt] glib-networking-2.36.2-1.fc19: JS_AbortIfWrongThread: Process /usr/libexec/glib-pacrunner was killed by signal 11 (SIGSEGV)
Last modified: 2014-04-15 11:45:16 EDT
Version-Release number of selected component:
runlevel: N 5
Thread no. 1 (10 frames)
#0 JS_AbortIfWrongThread at /usr/src/debug/mozjs17.0.0/js/src/jsapi.cpp:7036
#1 js::DestroyContext at /usr/src/debug/mozjs17.0.0/js/src/jscntxt.cpp:380
#2 ~mozjs_pacrunner at /usr/src/debug/libproxy-0.4.11/libproxy/modules/pacrunner_mozjs.cpp:151
#3 mozjs_pacrunner::~mozjs_pacrunner at /usr/src/debug/libproxy-0.4.11/libproxy/modules/pacrunner_mozjs.cpp:154
#4 libproxy::pacrunner_extension::get at /usr/src/debug/libproxy-0.4.11/libproxy/extension_pacrunner.cpp:37
#5 libproxy::proxy_factory::run_pac at /usr/src/debug/libproxy-0.4.11/libproxy/proxy.cpp:419
#6 libproxy::proxy_factory::get_proxies at /usr/src/debug/libproxy-0.4.11/libproxy/proxy.cpp:216
#7 px_proxy_factory_get_proxies at /usr/src/debug/libproxy-0.4.11/libproxy/proxy.cpp:463
#8 get_libproxy_proxies at glibproxyresolver.c:145
#9 g_task_thread_pool_thread at gtask.c:1242
Created attachment 787777 [details]
Created attachment 787778 [details]
Created attachment 787779 [details]
Created attachment 787780 [details]
Created attachment 787781 [details]
Created attachment 787782 [details]
Created attachment 787783 [details]
Created attachment 787784 [details]
Created attachment 787785 [details]
Created attachment 787786 [details]
Created attachment 787787 [details]
*** Bug 1004114 has been marked as a duplicate of this bug. ***
*** Bug 1004534 has been marked as a duplicate of this bug. ***
libproxy-0.4.11-6.fc19 has been submitted as an update for Fedora 19.
libproxy-0.4.11-7.fc20 has been submitted as an update for Fedora 20.
libproxy-0.4.11-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
libproxy-0.4.11-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I just have this happened, and ABRT said this bug is already reported here.
$ rpm -q libproxy
What other information is needed?
Have you logged out or rebooted since getting the libproxy-0.4.11-6.fc19.x86_64 update? If not, then you would have still been running glib-pacrunner against the old version of the library, so it would eventually crash. At this point it should not crash again.
I can't remember if I have rebooted or not. I just rebooted and if problem occurs again, I'll report here, thanks.
OK, I just found that I can reliably reproduce this problem:
1 start gnome-tweak-tool
2 In the 'Shell Extensions' tab, click 'Get more extensions'
3 Firefox starts and abrt pops up at the down right corner.
[ 14.026757] pool: segfault at 0 ip 00007f430471fc12 sp 00007f4301eb39d0 error 6 in libmozjs-17.0.so[7f43046d3000+3a7000]
[ 19.403704] pool: segfault at 0 ip 00007f85e72aac12 sp 00007f85e604d9d0 error 6 in libmozjs-17.0.so[7f85e725e000+3a7000]
[ 65.977555] pool: segfault at 0 ip 00007f9445e96c12 sp 00007f94377fd9d0 error 6 in libmozjs-17.0.so[7f9445e4a000+3a7000]
[ 125.106667] pool: segfault at 0 ip 00007fc98e127c12 sp 00007fc98d0d79d0 error 6 in libmozjs-17.0.so[7fc98e0db000+3a7000]
[ 125.877657] pool: segfault at 0 ip 00007f9054306c12 sp 00007f90528a89d0 error 6 in libmozjs-17.0.so[7f90542ba000+3a7000]
[ 162.346353] pool: segfault at 0 ip 00007f790c513c12 sp 00007f79089ba9d0 error 6 in libmozjs-17.0.so[7f790c4c7000+3a7000]
can you attach your proxy.pac file? (If you want to edit it first to remove confidential stuff, make sure that the bug still occurs with the edited version.)
I just made a simplified version and I can still reproduce the problem with it.
function FindProxyForURL(url, host)
return "PROXY host_name_for_my_proxy_server:911";
The above is from the autoproxy.pac for firefox, but perhaps it's not that proxy setting caused the problem, it should be the proxy I set in system-settings for network proxy, where I used an URL for automatic setting: http://autoproxy.x.com. I wget the index.html and saw there are a whole lot of condition checking and proxy host setting involved.
I ceased to use that URL now and directly set proxy host in system network proxy setting, no problem has occurred till now. So problem solved I would say, thanks!
BTW are you using the autoproxy2pac to generate the pac?(I'm the comaintainer of autoproxy/gfwlist.)
No, I just use the URL as the auto proxy setting.
I still see these with
and abrt always claims that the problem has already been reported here.
libproxy-0.4.11-7.fc19 has been submitted as an update for Fedora 19.
libproxy-0.4.11-8.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libproxy-0.4.11-8.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
still see this bug with libproxy-0.4.11-8.fc20 when install some extensions
did you see it more than once? You might crash once more after installing the update if you didn't log out and back in, since you'd still have the old glib-pacrunner binary running
yes,actually,I reproduce it 3 times ,after the reboot.
Created attachment 824120 [details]
backtrace generated with 2.38.1-1 fc20 + reboot
I can reproduce it many times a day, after latest updates and reboot.
I managed to get some output from abrt before it declared this already solved:
- attached a new backtrace
ABRT Server: URL=https://retrace.fedoraproject.org/faf/reports/bthash/9dba29ee20a1678e8a34458bcd1c1c93e22d3c03
Mikko, that stack trace appears to be against the older version of libproxy; you need libproxy 0.4.11-8, which is only in updates-testing, to fix the bug.
A stack trace against the new version of libproxy (from anyone) would be useful.
rpm -q libproxy
Nov 13 11:23:34 yum: Updated: libproxy-0.4.11-8.fc20.x86_64
Nov 13 11:23:35 yum: Updated: libproxy-mozjs-0.4.11-8.fc20.x86_64
Nov 13 11:23:35 yum: Updated: libproxy-python-0.4.11-8.fc20.noarch
Hmm. You might be right that the stacktrace could be from the yesterday morning just before I did last yum update. I'll monitor the situation more tomorrow and report if the bug is solved from my part.
Thank you for your effort and hand holding.
still doesn't work for me ,the abrt popup comes randomly,sometimes when I try to install some extensions,gnome-tweak-tool GUI disapper with the below message left:
(process:2400): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
I am also getting the abrt error for glibnetworking multiple times everyday (last count was 26).
as mentioned before, a stack trace with the latest libproxy (ideally with libproxy-debuginfo installed as well) would be useful. I can't reproduce this.
Just as I said,I've installed both libproxy and libproxy-debuginfo,and can reproduce this many times:the abrt popup comes randomly when I try to install some extensions.At the same time,gnome-tweak-tool GUI disappear with message:(process:2400): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Segmentation fault(core dump)
yes, I know *you* can reproduce it, but I can't, and I need to see a stack trace of the crash against current libproxy in order to see where it's crashing now
I confirm that upgrading to libproxy-0.4.11-8.fc20 fixed the problem.
no more crashes and no more cpu at 100% (journalctl and/or abrt handling crashes)
Created attachment 828585 [details]
I reproduced this bug with libproxy-0.4.11-8.fc20 one more time to get the stack trace which has been attached
ah, sorry, you need to do "thread apply all backtrace" (or "t a a bt") if you're grabbing the stack trace by hand. Otherwise you only get one thread, and it's generally the wrong one.
Hi,the tested VM crashed to black when I tried to start it :(.I had a fresh install on the VM,and installed gnome-tweak-tool-3.10.1-2,this time I'm unable to reproduce this bug any more.The libproxy version is 0.4.11-7.fc20.
FYI:gnome-tweak-tool-3.10.1-2+libproxy-0.4.11-8.fc20 works fine too
the gnome-tweak-tool‘version on the crashed VM is 3.10.0-2
BTW. Same problem, same fix. Only for me it was happening continuously, e.g. every few seconds.
Can you clarify "same problem, same fix"? Are you seeing this bug with libproxy-0.4.11-8.fc20?
Here are the error messages I was getting until I installed the new proxy package from updates-testing:
Mar 2 14:24:44 briemersw kernel: [ 7778.776698] pool: segfault at 0 ip 0000003d5e44de72 sp 00007feb913fe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:45 briemersw kernel: [ 7779.820286] pool: segfault at 0 ip 0000003d5e44de72 sp 00007f0287ffe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:46 briemersw kernel: [ 7780.850851] pool: segfault at 0 ip 0000003d5e44de72 sp 00007fe4120fe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:48 briemersw kernel: [ 7781.889396] pool: segfault at 0 ip 0000003d5e44de72 sp 00007fde964fe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:49 briemersw kernel: [ 7782.925663] pool: segfault at 0 ip 0000003d5e44de72 sp 00007f01095fe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:50 briemersw kernel: [ 7783.958201] pool: segfault at 0 ip 0000003d5e44de72 sp 00007f2503ffe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:51 briemersw kernel: [ 7785.006032] pool: segfault at 0 ip 0000003d5e44de72 sp 00007f26cfdfe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
Mar 2 14:24:52 briemersw kernel: [ 7786.033601] pool: segfault at 0 ip 0000003d5e44de72 sp 00007f22b8efe9b0 error 6 in libmozjs-17.0.so[3d5e400000+3b3000]
I believe it was happening so frequently, because I have the following in DNSMASQ on my router:
This in turn was actually causing other failures, which are hard to determine how they are related. For example, I have an external drive that kept turning itself off rather than auto mounting the drive. I don't have a clue how that could be related, but updating the package resolved it...
ok, there don't seem to be any reproducible reports with libproxy-0.4.11-8.fc20, so I'm re-closing this
This still tops the F20 problem tracker:
libproxy-0.4.11-8.fc20 has never made it to stable due to negative karma:
Please consider reopening.
My F20's logs are full of glib-pacrunner/libmozjs crashes, please reopen
(In reply to Tomas Toth from comment #52)
> libproxy-0.4.11-8.fc20 has never made it to stable due to negative karma:
Sigh. Then people who are having this problem should install that update, restart, verify that the bug has gone away for them, and then add karma to the package.
(Or someone could tell me the koji magic to force the build to go out despite its -1 karma? At least one of the -1's is 100% bogus, and based on the fact that the identical f19 update got +3, the other -1 is presumably bogus as well.)
Voted for the package, but karma is still -1...
An automatic report was generated for this bug when trying to install a gnome-shell extension from https://extensions.gnome.org/extension/615/appindicator-support/
I'm going through a proxy with authentication (configured in the network settings).
Actually, pacrunner from 0.4.11-8 occupies all my CPU after reboot.
It seems that it is started upon Empathy attempt to login to GTalk and Facebook.
libproxy-0.4.11-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Dan: it's not Koji magic you need, but Bodhi. I think you can't push it now as it doesn't meet the criteria:
" At the time of the request to stable, the update needs to have either a Bodhi karma sum of 2 OR
It must spend at least 14 days in updates-testing AND have no negative Bodhi karma points."
I can ask those who filed negative feedback to re-test, if you think the issues are bogus.
libproxy-0.4.11-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.