abrt 1.0.2 detected a crash. How to reproduce ----- 1. Browsed to http://us1.irabankratings.com/MoveYourMoney/IRACommunityZip.asp?affiliate=moveyourmoney&zip=94040&submit=Search 2. Hit "File->Print" 3. Comment: Was trying to print..... Just hit File->Print Attached file: backtrace cmdline: /usr/lib64/firefox-3.6/firefox component: firefox executable: /usr/lib64/firefox-3.6/firefox kernel: 2.6.32.2-18.fc13.x86_64 package: firefox-3.6.1-0.9.b5.fc13 rating: 4 reason: Process was terminated by signal 11 (Segmentation fault)
Created attachment 382591 [details] File: backtrace
#2 <signal handler called> No symbol table info available. #3 0x00007f7d37aa01d0 in ?? () No symbol table info available. #4 0x0000003eaec0ffc8 in mutex_init (lock=0x3eaee745d0, just_check=1) at ath.c:132 err = 0 #5 0x0000003eaec1023a in _gcry_ath_mutex_lock (lock=0x3eaee745d0) at ath.c:186 ret = <value optimized out> __PRETTY_FUNCTION__ = "_gcry_ath_mutex_lock" #6 0x0000003eaec44b70 in lock_pool () at random-csprng.c:298 err = <value optimized out> #7 0x0000003eaec44cbe in initialize () at random-csprng.c:327 No locals. #8 0x0000003eaec44e25 in _gcry_rngcsprng_create_nonce (buffer= 0x7fff1b2ac10f, length=1) at random-csprng.c:1330 nonce_buffer = "\255\037\235N\317\314c\341\222\321m\277\306C?/\345\000\a&\016e\003An\223\304\370" nonce_buffer_initialized = 1 my_pid = 2404 apid = <value optimized out> p = <value optimized out> n = <value optimized out> err = <value optimized out> #9 0x0000003eb2c3c817 in wrap_gcry_rnd_init (ctx=<value optimized out>) at rnd-libgcrypt.c:39 c = 0 '\000' #10 0x0000003eb2c3aaac in _gnutls_rnd_init () at random.c:39 No locals. #11 0x0000003eb2c2c156 in gnutls_global_init () at gnutls_global.c:240 result = 0 res = 0 #12 0x00007f7d27dd3134 in httpInitialize () at http.c:1212 action = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0} #13 0x00007f7d27dd31f5 in _httpCreate (host= 0x7f7d384e6a60 "/var/run/cups/cups.sock", port=631, encryption= HTTP_ENCRYPT_IF_REQUESTED) at http.c:447 http = <value optimized out> addrlist = <value optimized out> service = "tM\212U\000\000\000\000\230\253^1}\177", '\000' <repeats 34 times>, "XC\327.}\177\000\000\260\302*\033\377\177\000\000PJ\333'}\177\000\000\000x\327.}\177\000\000\320?6\026\000\000\000\000\377\377\377\377\000\000\000\000\240\063\333'}\177\000\000\005\000\000\000\000\000\000\000H\347$", '\000' <repeats 13 times>, "\002@", '\000' <repeats 15 times>, "\020\333'}\177\000\000\301\345\200\237>\000\000\000\005", '\000' <repeats 16 times>"\200, ^1}\177\000\000PJ\333'}\177\000\000\005\000\000\000\060\000\000\000\000\350\256\060}\177", '\000' <repeats 26 times>, "\025K\201\237>", '\000' <repeats 11 times>"\200, \202!\240>\000" #14 0x00007f7d27dd32ea in httpConnectEncrypt (host=<value optimized out>, port=<value optimized out>, encryption=<value optimized out>) at http.c:404 http = <value optimized out> -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. First of all, could we get output of the command, saved in a text file and attached to this bug: $ rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin* Please also install firefox-debuginfo. # debuginfo-install firefox Then run firefox inside the gdb debugger. Please do the following: $ firefox -g Stuff will appear. Ignore this until you get the gdb command prompt, then do: (gdb) run Now, firefox should start up. Use it and reproduce the crash. When firefox crashes, you should be back to the gdb prompt. Now do: (gdb) thread apply all backtrace More screens of stuff will occur. Copy all of this part to your editor of choice, such as gedit, and save it as an uncompressed file and attach it to this bug report. We will review this issue again once you've had a chance to attach this information. Thanks in advance, for your extra efforts. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 382685 [details] Output of "rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin*" As requested, output of "rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin* >firefox.txt"
Created attachment 382687 [details] gdb backtrace of crash (as requested) As requested, here is backtrace obtained running "firefox -g; thread apply all bt full" Hope this helps. Let me know if I can provide more....
Created attachment 382689 [details] "complete" gdb backtrace Believe the previous attachment was not a complete backtrace.... Cut/paste error? Believe this one should be complete.
Here is the URL that causes the segfault each time I try to print: http://us1.irabankratings.com/MoveYourMoney/IRACommunityZip.asp?affiliate=moveyourmoney&zip=94040&submit=Search Happens every time....
Thank you VERY much for your extra efforts. Assigning to stransky. Setting keyword Triaged, status stays NEW (RAWHIDE) per new triage policy. This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 383252 [details] Another "firefox -g" trace generated trying to pring "https://bugzilla.redhat.com/frontpage.cgi" Looks like printing is generally sick, at least for me. I got this backtrace trying to print "https://bugzilla.redhat.com/frontpage.cgi". In fact, I think printing no longer works for me, period. Some more info from me useful?
Created attachment 383686 [details] gdb backtrace segfaulting trying to print with firefox-3.6.1-0.10.rc1.fc13.x86_64 Updated to xulrunner-debuginfo-1.9.2.1-0.9.rc1.fc13.x86_64 firefox-3.6.1-0.10.rc1.fc13.x86_64 xulrunner-1.9.2.1-0.9.rc1.fc13.x86_64 xulrunner-devel-1.9.2.1-0.9.rc1.fc13.x86_64 Firefox still crashes every time I try to print. This one is from attempting to print "https://bugzilla.redhat.com/frontpage.cgi". Epiphany has no problem printing this or any other URL. Is there something else I can do/something else I can provide to help this along?
For completeness, also update to openssl-1.0.0-0.19.beta4.fc13.x86_64 openssl-devel-1.0.0-0.19.beta4.fc13.x86_64 openssl-debuginfo-1.0.0-0.19.beta4.fc13.x86_64
*** Bug 555709 has been marked as a duplicate of this bug. ***
*** Bug 556118 has been marked as a duplicate of this bug. ***
Still crashes with xulrunner-1.9.2.1-0.10.rc2.fc13.x86_64 firefox-3.6.1-0.11.rc2.fc13.x86_64 Crashes when you select "Page Setup" too. Downloading debuginfo packages to provide backtrace......
Created attachment 385104 [details] "script" capture of "gdb /usr/lib64/firefox*/firefox coredump; thread apply all bt full" I get segfaults/coredumps trying to print, etc. This one was produced by selecting "File->Page Setup". Any known workaround? I have to run empathy to print anything..... :-( Anything more I can provide/do?
Created attachment 385110 [details] "firefox -safe-mode" backtrace (trying to print) Backtrace running "firefox -safe-mode" and trying to print.....
Fails in the same way if I start firefox with a clean new profile.
Created attachment 386168 [details] Output of "firefox -g" showing crash This continues to segfault with: [root@tlondon ~]# rpm -qa firefox\* \*xul\* firefox-3.6.1-1.fc13.x86_64 xulrunner-devel-1.9.2.1-1.fc13.x86_64 firefox-debuginfo-3.6.1-1.fc13.x86_64 xulrunner-1.9.2.1-1.fc13.x86_64 xulrunner-debuginfo-1.9.2.1-1.fc13.x86_64 [root@tlondon ~]# Crashes each and every time I try to print/page setup/etc. I attach the latest output from "firefox -g" showing "firefox -g; run; where; thread apply all bt full" As above, I can print with epiphany and chrome.
I'll see if I can't poke the devs a little to get this a little loving for you. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
One more data point: Thinking that maybe something in my '~/.mozilla' might be causing this, I created a brand new user, logged in as that user, started firefox, and selected 'File->Print' on the "Welcome to Firefox" page. I got what appears to be the same crash: Jan 23 18:24:05 tlondon kernel: Process 20586(firefox) has RLIMIT_CORE set to 0 Jan 23 18:24:05 tlondon kernel: Aborting core My next thought would be to remove/clean-out all my printer definitions, but I'm reluctant to do so if that would remove any 'smoking guns'.....
Hi, Don't know if it's relevant, but I've tried the latest nightly build from Mozilla [1]. Printing also crashes this build version. Martin Kho [1] ftp://ftp.mozilla.org/pub/firefox/nightly/latest-firefox-3.6.x/
Hi, Running firefox -d and then try to print gives the following message: /usr/lib64/firefox-3.6/run-mozilla.sh: line 131: 10410 Segmentation fault "$prog" ${1+"$@"} Hope this helps. Martin Kho
*** Bug 559769 has been marked as a duplicate of this bug. ***
A bit of further information: I've deleted all my printers (via cups), and then added them anew. No change: firefox still segfaults as above.
Notable addition: Thunderbird has the same crash. spot@pterodactyl ~]$ rpm -q xulrunner firefox thunderbird xulrunner-1.9.2.1-1.fc13.x86_64 firefox-3.6.1-1.fc13.x86_64 thunderbird-3.0.1-1.fc13.x86_64
*** Bug 559826 has been marked as a duplicate of this bug. ***
Any movement/hope on this one? Anything more I can do/information I can provide?
I meet with the triagers and some of the devs during the week. I'll make a note to get one of them to see if this is being seen on Monday. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I've backed firefox/xulrunner back to firefox-3.6.1-0.6.b4.fc13.x86_64.rpm firefox-debuginfo-3.6.1-0.6.b4.fc13.x86_64.rpm xulrunner-1.9.2.1-0.5.b4.fc13.x86_64.rpm xulrunner-debuginfo-1.9.2.1-0.5.b4.fc13.x86_64.rpm xulrunner-devel-1.9.2.1-0.5.b4.fc13.x86_64.rpm [Believe this is end of November.] Still segfaults..... My (probably naive) conjecture is that something changed in a dependent package that is causing this. I've tried reverting some other packages updated near the beginning of January (including nss*, openssl*) but no joy: still segfaults. I've noticed that the 3 posters to this BZ seeem to be running x86_64.
I am seeing this on i686 hardware.
I've been seeing this ever since switching to F13, on x86-64. jlaska confirms it on his Rawhide system. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 390583 [details] gdb trace output of calls to "mutex_init()" showing rewrite of "ops" structure Sorry in advance for my humble debugging efforts...... I attached the following commands to a breakpoint at "mutex_init()": (gdb) break mutex_init Function "mutex_init" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (mutex_init) pending. (gdb) commands 1 Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". >print ops >cont >end (gdb) Running firefox produces the "trace" output attached. All the calls to mutex_init(), except the last one, show the following values for "ops": Breakpoint 1, mutex_init (lock=0x7f72f0949e00, just_check=1) at ath.c:128 128 { $30 = {option = 3, init = 0, mutex_init = 0x7f72d78d2270 <gcry_pthread_mutex_init>, mutex_destroy = 0x7f72d78d2210 <gcry_pthread_mutex_destroy>, mutex_lock = 0x7f72d78d21d0 <gcry_pthread_mutex_lock>, mutex_unlock = 0x7f72d78d2190 <gcry_pthread_mutex_unlock>, read = 0, write = 0, select = 0, waitpid = 0, accept = 0, connect = 0, sendmsg = 0, recvmsg = 0} The last call (the one that appears to produce the segfault) shows: Breakpoint 1, mutex_init (lock=0x7f72f094a010, just_check=1) at ath.c:128 128 { $58 = {option = 3, init = 0, mutex_init = 0x7f72d78d2270, mutex_destroy = 0x7f72d78d2210, mutex_lock = 0x7f72d78d21d0, mutex_unlock = 0x7f72d78d2190, read = 0, write = 0, select = 0, waitpid = 0, accept = 0, connect = 0, sendmsg = 0, recvmsg = 0} Program received signal SIGSEGV, Segmentation fault. 0x00007f72d78d21d0 in ?? () (gdb) Unfortunately, these seem not to be valid pointers to functions, and hence the segfault. Is this useful? helpful?
A bit more: Notice that the values printed for "ops" are the save for the calls that "work" as for the last call. Notice that the segfault occurs on a call to "ops.mutex_lock()", even though that address is the same as with the previous calls..... I augmented the gdb run adding an explicit "x/i ops.mutex_lock" to the list of commands executed at the breakpoint for "mutex_init()". Here is what I get for the last few breakpoints: Breakpoint 1, mutex_init (lock=0x7fcc2644d4f0, just_check=1) at ath.c:128 128 { $27 = {option = 3, init = 0, mutex_init = 0x7fcc0e225270 <gcry_pthread_mutex_init>, mutex_destroy = 0x7fcc0e225210 <gcry_pthread_mutex_destroy>, mutex_lock = 0x7fcc0e2251d0 <gcry_pthread_mutex_lock>, mutex_unlock = 0x7fcc0e225190 <gcry_pthread_mutex_unlock>, read = 0, write = 0, select = 0, waitpid = 0, accept = 0, connect = 0, sendmsg = 0, recvmsg = 0} 0x7fcc0e2251d0 <gcry_pthread_mutex_lock>: sub $0x18,%rsp Breakpoint 1, mutex_init (lock=0x7fcc2644d4f0, just_check=1) at ath.c:128 128 { $28 = {option = 3, init = 0, mutex_init = 0x7fcc0e225270 <gcry_pthread_mutex_init>, mutex_destroy = 0x7fcc0e225210 <gcry_pthread_mutex_destroy>, mutex_lock = 0x7fcc0e2251d0 <gcry_pthread_mutex_lock>, mutex_unlock = 0x7fcc0e225190 <gcry_pthread_mutex_unlock>, read = 0, write = 0, select = 0, waitpid = 0, accept = 0, connect = 0, sendmsg = 0, recvmsg = 0} 0x7fcc0e2251d0 <gcry_pthread_mutex_lock>: sub $0x18,%rsp Breakpoint 1, mutex_init (lock=0x7fcc2644d4f0, just_check=1) at ath.c:128 128 { $29 = {option = 3, init = 0, mutex_init = 0x7fcc0e225270, mutex_destroy = 0x7fcc0e225210, mutex_lock = 0x7fcc0e2251d0, mutex_unlock = 0x7fcc0e225190, read = 0, write = 0, select = 0, waitpid = 0, accept = 0, connect = 0, sendmsg = 0, recvmsg = 0} 0x7fcc0e2251d0: Cannot access memory at address 0x7fcc0e2251d0 (gdb) Notice that the "x/i ops.mutex_lock" (aka. "x/i 0x7fcc0e225210") works for all but the last call to mutex_init(). Could there be an "extra dlclose()" or something?
If I kill off cupsd (via "service cups stop"), I no longer get this crash. Of course, I can then only "print to file"..... A question to the other posters: do you have Postscript printers configured? Just non-Postscript? Any hope of having someone who "knows the code" look at this?
Hi, I've a postscript printer configured and when I stop cupsd I get the print dialog. I'm currently trying out Firefox 3.7a2pre. Guess ... It also crashes on the printer dialog. Looks like the issue has to do with cups? Martin Kho
Hi, By accident, I did choose "Print preview". This crashed Firefox (both versions 3.6 and 3.7a2pre) ;-( Martin Kho
Hi, ...and after starting cupsd again, Firefox didn't crash on "Print preview". Martin Kho
Continue to segfault on every attempt to print/preview/setup with firefox-3.6.1-2.fc14.x86_64. Firefox is the only program having problems printing/connecting to cups: I have no problem printing from chrome, epiphany or any other program (I don't use thunderbird). Is there anything more I can do to encourage/support progress here? I haven't been able to print from firefox since the beginning of January (end of December?). Here are my "currently installed packages": xulrunner-devel-1.9.2.1-3.fc14.x86_64 firefox-debuginfo-3.6.1-2.fc14.x86_64 xulrunner-1.9.2.1-3.fc14.x86_64 cups-libs-1.4.2-31.fc14.x86_64 cups-debuginfo-1.4.2-31.fc14.x86_64 xulrunner-debuginfo-1.9.2.1-3.fc14.x86_64 gnutls-debuginfo-2.8.5-4.fc13.x86_64 cups-pk-helper-0.0.4-12.fc14.x86_64 cups-devel-1.4.2-31.fc14.x86_64 cups-1.4.2-31.fc14.x86_64 firefox-3.6.1-2.fc14.x86_64 gnutls-devel-2.8.5-4.fc13.x86_64 gnutls-2.8.5-4.fc13.x86_64 Program received signal SIGSEGV, Segmentation fault. 0x00007f6d354d2230 in ?? () (gdb) where #0 0x00007f6d354d2230 in ?? () #1 0x00000039bb00ffd8 in mutex_init (lock=0x39bb2744f0, just_check=1) at ath.c:132 #2 0x00000039bb01024a in _gcry_ath_mutex_lock (lock=0x39bb2744f0) at ath.c:186 #3 0x00000039bb044b90 in lock_pool () at random-csprng.c:298 #4 0x00000039bb044cde in initialize () at random-csprng.c:327 #5 0x00000039bb044e45 in _gcry_rngcsprng_create_nonce (buffer=0x7fffc68d53ff, length=1) at random-csprng.c:1330 #6 0x0000003955c3c827 in ?? () #7 0x0000000000000277 in ?? () #8 0x0000000000000000 in ?? () (gdb) print ops $1 = {option = 3, init = 0, mutex_init = 0x7f6d354d22d0, mutex_destroy = 0x7f6d354d2270, mutex_lock = 0x7f6d354d2230, mutex_unlock = 0x7f6d354d21f0, read = 0, write = 0, select = 0, waitpid = 0, accept = 0, connect = 0, sendmsg = 0, recvmsg = 0} (gdb)
*** Bug 569569 has been marked as a duplicate of this bug. ***
See also bug #544619, which is the last time that code in libcups was touched.
Yea! Downgrading cups to cups-1.4.2-18.fc13.x86_64.rpm and restarting cups "makes this work for me". [I didn't try cups-1.4.2-19.fc13 or later.] I'll cross post this on https://bugzilla.redhat.com/show_bug.cgi?id=544619
Hi, Firefox and cups-1.4.2-31.fc14.x86_64 -> crash :-( Martin Kho
a) firefox dlopens cups b) cups calls... gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); gnutls_global_init(); Due to rhb#544619# the idea was to ensure that libgcrypt gets locked to avoid multiple threads using neon (that itself may use libgcrypt) from trampling over their shared libgcrypt. Hence the gcry_control added to cups (along the lines suggested at http://www.gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html) to make sure that if cups + neon is used in an app and cups is used first then all works well if multiple threads use neon later one. c) firefox dlcloses cups d) firefox dlopens cups e) cups calls... gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); gnutls_global_init(); In libgcrypt's src/global.c case GCRYCTL_SET_THREAD_CBS: err = ath_install (va_arg (arg_ptr, void *), any_init_done); any_init_done is still true from the *last* init, and ath_install is effectively a no-op if any_init_done is true. So the new pthread stuff isn't installed, and libgcrypt still points to the old info which was destroyed at the first dlclose of cups. Its all a bit unfortunate. If e.g. libgcrypt had way to query the GCRYCTL_SET_THREAD_CBS info then libs using it could either a) store a copy of the old info if it existed, install their own on their init and restore the old one on their deinit. b) only install one if one didn't exist (possible now) and *remove* their one on deinit (not possible now) Its not really practical in general of course for the *app* to call gcry_control (GCRYCTL_SET_THREAD_CBS...) because how is it to know that libgcrypt is being used by any of its libraries. Though that would solve the problem in this case seeing as any other GCRYCTL_SET_THREAD_CBS would be ignored, and the one installed during dlopen of cups wouldn't apply. So long and short of it is that it's currently hopeless to use GCRYCTL_SET_THREAD_CBS in a library because that library can be dlclosed, destroying the locking functions that were installed into libgcrypt.
In the absence of an improvement in libgcrypt (unless I'm shown to be totally wrong) it looks to me that 1. The installation of the thread callbacks in cups has to be rolled back. 2. In theory any uses of gcry_control (GCRYCTL_SET_THREAD_CBS in any other libs should also be removed :-) 3. In theory every app that uses threads which use functions that themselves might use libgcrypt, which I guess is theoretically all of them :-), has to lock them unless it happens to use libgcrypt directly in which case gcry_control (GCRYCTL_SET_THREAD_CBS can be used direcly in the apps init
..or, any application which dlopen()s libraries that might use gcrypt should use RTLD_NODELETE. But again, I guess theoretically that's all of them...
cups-1.4.2-33.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/cups-1.4.2-33.fc13
Changing component to cups.
libgcrypt deficiency filed as bug #569803.
*** Bug 559940 has been marked as a duplicate of this bug. ***
cups-1.4.2-33.fc14.x86_64 (and friends) "work for me". Realize there may be a deeper issue here, but thanks for this.
cups-1.4.2-33.fc13.i686 cleared up the problem I was having with FF-3.6.1-1 crashing on print. ty
cups-1.4.2-33.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-3343
yup, seems not to crash here with 1.4.2-33 too. thanks.
*** Bug 570185 has been marked as a duplicate of this bug. ***
cups-1.4.2-26.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/cups-1.4.2-26.fc11
cups-1.4.2-28.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/cups-1.4.2-28.fc12
cups-1.4.2-33.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.4.2-28.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.4.2-26.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Marking this on the [[Common F13 bugs]] page on the wiki too. https://fedoraproject.org/wiki/Common_F13_bugs
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #43) > any_init_done is still true from the *last* init, and ath_install is > effectively a no-op if any_init_done is true. So the new pthread stuff isn't > installed, and libgcrypt still points to the old info which was destroyed at > the first dlclose of cups. More specifically, the actual item that is no longer in memory is the check_init_lock mutex created by the implementation of gcry_pthread_mutex_init() hidden inside the 'GCRY_THREAD_OPTION_PTHREAD_IMPL' macro. I think what we actually need libgcrypt to do is remember all of the thread callbacks it is given during initialization, and provide a mechanism for invalidating a set of callbacks. On invalidation it needs to install one (any) of the other sets of callbacks. (Once the last set of callbacks is invalidated it's time to exit anyway.)