Bug 486745 - firefox hangs eating CPU
Summary: firefox hangs eating CPU
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 10
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-21 17:14 UTC by D. Hugh Redelmeier
Modified: 2018-04-11 09:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-06 07:08:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description D. Hugh Redelmeier 2009-02-21 17:14:05 UTC
Description of problem:
Firefox hung on me.  I was browsing bugzilla(!) with respect to a different firefox bug when firefox stopped refreshing the screen.  The CPU meter pegged: 100% CPU load.

(Surely I'm not the first to hit this bug but my search of a report here came up empty-handed.)

Version-Release number of selected component (if applicable):
firefox-3.0.6-1.fc10.x86_64


How reproducible:
I hope not at all.  This is the first I've seen of this particular bug

Steps to Reproduce:
unknown
  
Actual results:
CPU-eating loop encountered in firefox.

Expected results:
normal browsing.

Additional info:
I'm entering this using Konqueror: I'm still examining the bad firefox with GDB.
Konqueror seems a bit sluggish, but I don't know how it should behave since I never use it.

My firefox has a lot of windows and tabs open.
I don't have any Flash plugin installed.

Here is the output of gdb bt:
(gdb) bt
#0  SearchTable (table=0x7fff8c1ac138, key=0x500000000, keyHash=4294967294, op=PL_DHASH_ADD) at pldhash.c:440
#1  0x000000369560a812 in PL_DHashTableOperate (table=0x7fff8c1ac138, key=0x500000000, op=<value optimized out>) at pldhash.c:634
#2  0x000000369564879c in GCGraphBuilder::AddNode (this=0x7fff8c1ac100, s=0x7f6f5663e730, aParticipant=0x12232b8) at nsCycleCollector.cpp:1285
#3  0x00000036956488a3 in GCGraphBuilder::AddNode () at nsCycleCollector.cpp:1237
#4  GCGraphBuilder::NoteScriptChild (this=0x7fff8c1ac100, langID=<value optimized out>, child=0x500000000) at nsCycleCollector.cpp:1458
#5  0x0000003a6083ad31 in JS_CallTracer (trc=0x7fff8c1ac138, thing=0x500000000, kind=0) at jsgc.c:2449
#6  0x0000003a6087adb5 in js_TraceScript (trc=0x7fff8c1ac040, script=0xb4c4f50) at jsscript.c:1583
#7  0x0000003a60837d3d in fun_trace (trc=0x7fff8c1ac040, obj=0x10852a10) at jsfun.c:1406
#8  0x0000003a608512c3 in js_TraceObject (trc=0x7fff8c1ac040, obj=0x10852a10) at jsobj.c:5067
#9  0x0000003694e35e9b in nsXPConnect::Traverse (this=0x1223290, p=0x10852a10, cb=@0x7fff8c1ac100) at nsXPConnect.cpp:935
#10 0x0000003695648103 in GCGraphBuilder::Traverse (this=0x7fff8c1ac100, aPtrInfo=0x24e578c8) at nsCycleCollector.cpp:1319
#11 0x0000003695648161 in nsCycleCollector::MarkRoots (this=<value optimized out>, builder=@0x7fff8c1ac100) at nsCycleCollector.cpp:1513
#12 0x0000003695648bf4 in nsCycleCollector::BeginCollection (this=0x1192580) at nsCycleCollector.cpp:2368
#13 0x0000003694e36df2 in XPCCycleCollectGCCallback (cx=0x15eb050, status=JSGC_MARK_END) at nsXPConnect.cpp:440
#14 0x0000003a6083bc04 in js_GC (cx=0x15eb050, gckind=GC_NORMAL) at jsgc.c:3247
#15 0x0000003694e36063 in nsXPConnect::Collect (this=0x1223290) at nsXPConnect.cpp:529
#16 0x0000003695648d23 in nsCycleCollector::Collect (this=0x1192580, aTryCollections=1) at nsCycleCollector.cpp:2250
#17 0x00000036952150df in nsJSContext::CC () at nsJSEnvironment.cpp:3346
#18 0x000000369521548a in nsUserActivityObserver::Observe (this=0x154ad60, aSubject=<value optimized out>, 
    aTopic=0x36957886ac "user-interaction-inactive", aData=<value optimized out>) at nsJSEnvironment.cpp:270
#19 0x0000003695619357 in nsObserverList::NotifyObservers (this=0x2177ac0, aSubject=0x0, aTopic=0x36957886ac "user-interaction-inactive", 
    someData=0x0) at nsObserverList.cpp:128
#20 0x00000036956196a6 in nsObserverService::NotifyObservers (this=<value optimized out>, aSubject=0x0, 
    aTopic=0x36957886ac "user-interaction-inactive", someData=0x0) at nsObserverService.cpp:181
#21 0x00000036951369a2 in nsUITimerCallback::Notify (this=0x19ce3a0, aTimer=0x19384f0) at nsEventStateManager.cpp:210
#22 0x00000036956408f0 in nsTimerImpl::Fire (this=0x19384f0) at nsTimerImpl.cpp:403
#23 0x00000036956409f9 in nsTimerEvent::Run (this=<value optimized out>) at nsTimerImpl.cpp:490
#24 0x000000369563e552 in nsThread::ProcessNextEvent (this=0x1160470, mayWait=1, result=0x7fff8c1b43bc) at nsThread.cpp:510
#25 0x0000003695610242 in NS_ProcessNextEvent_P (thread=0x7fff8c1ac138, mayWait=1) at nsThreadUtils.cpp:227
#26 0x00000036955749a1 in nsBaseAppShell::Run (this=0x1221e60) at nsBaseAppShell.cpp:170
#27 0x0000003695433501 in nsAppStartup::Run (this=0x12ae8f0) at nsAppStartup.cpp:181
#28 0x0000003694e28fe0 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:3193
#29 0x0000000000401665 in main (argc=2, argv=0x7fff8c1b7dd8) at nsXULStub.cpp:364


Here is the result of a bunch of "next" commands from this point.  You will see the loop.  I cannot prove that this is infinite: the value of "hash1" changes when I probe it.  But note that the COLLISION_FLAG is already on when it is being added.
(gdb) n
445             if (MATCH_ENTRY_KEYHASH(entry, keyHash) &&
(gdb) n
427             if (NS_UNLIKELY(ENTRY_IS_REMOVED(entry))) {
(gdb) n
431                 if (op == PL_DHASH_ADD)
(gdb) n
432                     entry->keyHash |= COLLISION_FLAG;
(gdb) n
436             hash1 -= hash2;
(gdb) n
437             hash1 &= sizeMask;
(gdb) n
439             entry = ADDRESS_ENTRY(table, hash1);
(gdb) n
440             if (PL_DHASH_ENTRY_IS_FREE(entry)) {
(gdb) n
445             if (MATCH_ENTRY_KEYHASH(entry, keyHash) &&
(gdb) n
427             if (NS_UNLIKELY(ENTRY_IS_REMOVED(entry))) {
(gdb) n
431                 if (op == PL_DHASH_ADD)
(gdb) n
432                     entry->keyHash |= COLLISION_FLAG;
(gdb) n
436             hash1 -= hash2;
(gdb) n
437             hash1 &= sizeMask;
(gdb) n
439             entry = ADDRESS_ENTRY(table, hash1);
(gdb) n
440             if (PL_DHASH_ENTRY_IS_FREE(entry)) {
(gdb) n
445             if (MATCH_ENTRY_KEYHASH(entry, keyHash) &&
(gdb) n
427             if (NS_UNLIKELY(ENTRY_IS_REMOVED(entry))) {
(gdb) n
431                 if (op == PL_DHASH_ADD)
(gdb) n
432                     entry->keyHash |= COLLISION_FLAG;
(gdb) print entry->keyHash
$1 = 4294967295
(gdb) print COLLISION_FLAG
No symbol "COLLISION_FLAG" in current context.
(gdb) n
436             hash1 -= hash2;
(gdb) print entry->keyHash
$2 = 4294967295
(gdb) print hash2
$3 = 8355841
(gdb) print hash1
$4 = 4702575
(gdb) n
437             hash1 &= sizeMask;
(gdb) print hash1
$5 = 4291314030
(gdb) n
439             entry = ADDRESS_ENTRY(table, hash1);
(gdb) print hash1
$6 = 4735342
(gdb) n
440             if (PL_DHASH_ENTRY_IS_FREE(entry)) {
(gdb) print entry
$7 = (PLDHashEntryHdr *) 0x7f6f5683e6f0

Comment 1 Matěj Cepl 2009-03-01 23:13:31 UTC
Could you try to provide us with some more information about something which is different from the normal configuration? Obviously I cannot reproduce it here (I am in our bugzilla all the day every workday), and I don't see any crash in the backtrace. There must be something specific on your system or network configuration which triggers the issue. Do you have some interesting plugins which may cause this problem?

Comment 2 D. Hugh Redelmeier 2009-03-02 02:06:34 UTC
Thanks for looking at this.

I've not had this problem repeat since the report.

I don't know anything special about my configuration.

Comment 3 Matěj Cepl 2009-03-02 10:10:46 UTC
OK, so I will give you a month, and if you find anything let us know. Otherwise, I will close this bug as unreproducible.

Thanks for reporting this.

Comment 4 Martin Stransky 2009-05-06 07:08:43 UTC
Closing now...if you manage to reproduce it again please open this bug.


Note You need to log in before you can comment on or make changes to this bug.