abrt 1.0.2 detected a crash. How to reproduce ----- 1. Leave Firefox running overnight with eight tabs loaded 2. Power on monitor in morning. 3. Observe abrt signal icon saying Firefox had crashed. Comment ----- No idea what caused this. The tabs loaded were Google search results, six tabs from Badcaps Forums (tech site, low noise), one tab from [H]ard|Forum (tech site, low noise), and one tab with yahoo mail. I use NoScript and AdBlock so very little blinky-flashy noise comes through. Sometime during the night Firefox simply decided to go crash. Attached file: backtrace cmdline: /usr/lib/firefox-3.5.6/firefox component: firefox executable: /usr/lib/firefox-3.5.6/firefox kernel: 2.6.31.9-174.fc12.i686.PAE package: firefox-3.5.6-1.fc12 rating: 4 reason: Process was terminated by signal 11 (Segmentation fault)
Created attachment 381209 [details] File: backtrace
#3 <signal handler called> No symbol table info available. #4 0x062590d3 in PL_DHashTableOperate (table=0xbf878b98, key=0xb7556000, op= PL_DHASH_ADD) at pldhash.c:599 keyHash = <value optimized out> entry = <value optimized out> size = <value optimized out> deltaLog2 = <value optimized out> #5 0x062a0893 in GCGraphBuilder::AddNode (this=<value optimized out>, s=<value optimized out>, aParticipant=<value optimized out>) at nsCycleCollector.cpp:1338 e = <value optimized out> result = 0x0 #6 0x0597e74f in XPCJSRuntime::AddXPConnectRoots ( this=<value optimized out>, cx=<value optimized out>, cb=<value optimized out>) at xpcjsruntime.cpp:420 iter = 0xb7556000 acx = 0xb7556000 #7 0x0596865c in nsXPConnect::BeginCycleCollection ( this=<value optimized out>, cb=<value optimized out>) at nsXPConnect.cpp:572 No locals. #8 0x062a0e70 in nsCycleCollector::BeginCollection ( this=<value optimized out>) at nsCycleCollector.cpp:2453 i = 2 builder = {<nsCycleCollectionTraversalCallback> = { _vptr.nsCycleCollectionTraversalCallback = 0x6b1db60}, mNodeBuilder = {mNextBlock = 0xb7510040, mNext = @0xb7510044, mBlockEnd = 0x0}, mEdgeBuilder = {mCurrent = 0xb7510048, mBlockEnd = 0xb7510048, mNextBlockPtr = 0xb751004c}, mPtrToNodeMap = {ops = 0x0, data = 0x0, hashShift = 17, maxAlphaFrac = 192 '\300', minAlphaFrac = 64 '@', entrySize = 8, entryCount = 0, removedCount = 0, generation = 0, entryStore = 0x0}, mCurrPi = 0x0, mRuntimes = 0xb7510010} #9 0x062a0f23 in nsCycleCollector_beginCollection () at nsCycleCollector.cpp:3057 No locals. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Lacrocivious, I cannot find a good duplicate for this, so, if you are willing to do a little extra work (understand that this happened overnight, so response will be ... delayed), could you perform the following, and add the outputs asked for as ATTACHMENTS to this bug? 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 rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin* Please also install firefox-debuginfo (debuginfo-install is from yum-utils package). 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. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** This bug has been marked as a duplicate of bug 242370 ***
#3 <signal handler called> No symbol table info available. #4 0x062590d3 in PL_DHashTableOperate (table=0xbf878b98, key=0xb7556000, op= PL_DHASH_ADD) at pldhash.c:599 keyHash = <value optimized out> entry = <value optimized out> size = <value optimized out> deltaLog2 = <value optimized out> #5 0x062a0893 in GCGraphBuilder::AddNode (this=<value optimized out>, s=<value optimized out>, aParticipant=<value optimized out>) at nsCycleCollector.cpp:1338 e = <value optimized out> result = 0x0 #6 0x0597e74f in XPCJSRuntime::AddXPConnectRoots ( this=<value optimized out>, cx=<value optimized out>, cb=<value optimized out>) at xpcjsruntime.cpp:420 iter = 0xb7556000 acx = 0xb7556000 #7 0x0596865c in nsXPConnect::BeginCycleCollection ( this=<value optimized out>, cb=<value optimized out>) at nsXPConnect.cpp:572 No locals. #8 0x062a0e70 in nsCycleCollector::BeginCollection ( this=<value optimized out>) at nsCycleCollector.cpp:2453 i = 2 builder = {<nsCycleCollectionTraversalCallback> = { _vptr.nsCycleCollectionTraversalCallback = 0x6b1db60}, mNodeBuilder = {mNextBlock = 0xb7510040, mNext = @0xb7510044, mBlockEnd = 0x0}, mEdgeBuilder = {mCurrent = 0xb7510048, mBlockEnd = 0xb7510048, mNextBlockPtr = 0xb751004c}, mPtrToNodeMap = {ops = 0x0, data = 0x0, hashShift = 17, maxAlphaFrac = 192 '\300', minAlphaFrac = 64 '@', entrySize = 8, entryCount = 0, removedCount = 0, generation = 0, entryStore = 0x0}, mCurrPi = 0x0, mRuntimes = 0xb7510010} #9 0x062a0f23 in nsCycleCollector_beginCollection () at nsCycleCollector.cpp:3057 No locals. #10 0x05968f18 in XPCCycleCollectGCCallback (cx=<value optimized out>,
sorry, I shouldn't paste here the backtrace second time.
Reporter, could you please describe us what you have done to get to this point, and how we can reproduce this issue here? Is there anything special about your system, network, configuration which we need to replicate here in order to reproduce your problem please?
Created attachment 381604 [details] gdb log of (crash-less) firefox run for three full days
Created attachment 381605 [details] terminal text with requested version information and debuginfo-install output
I have not been able to reproduce this bug despite a gdb firefox run spanning three full days. At this point I suspect it may best be regarded as a Mysterious Cosmic Ray Bombardment Event and forgotten. As requested, I installed debuginfo packages and recorded output for version and installed-package information. Firefox loaded under gdb with the exact same tabs that had been open when the original crash occurred. During the run I did click the tabs and scroll them a few times over the three-day run, but did not otherwise use that computer, because the original crash occurred overnight while the computer was unattended. Firefox never crashed. I finally closed it normally, entered 'thread apply all bt' just in case, then closed gdb and the script log (attached .log file). Upon closure I was prompted with additional debuginfo-install packages, which I did install (terminal output is appended and documented in attached .txt file). However, Firefox has *not* been run with this second set of debuginfo packages installed. The information included in the attachments may well be overkill, for which if so I apologize. I have included it in the event that there is something useful within it. My sincere thanks to the bugwatchers and developers for assistance in this. I very much hope I have not wasted anyone's time.
Well, *I* for one think you have, but only because I've spent the last 10 minutes trying to figure out what Lacrocivious means... :) As far as the bug report goes...it's never a waste of any of our time to report one... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Closing as NOTABUG per reporter's request. Please don't hesitate to reopen with additional information in case you can make this bug usable again.