crash [@ PL_DHashTableEnumerate]

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
13 years ago
8 years ago

People

(Reporter: asrail, Assigned: graydon)

Tracking

({crash, regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments)

Reporter

Description

13 years ago
SeaMonkey trunk started to crash with this stack 20060106.
It does not happens while making something specific.
What I can say is that always I had Mail&News, Browser and Chatzilla opened and sent some emails.

Here is the stack:
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb74f3e66 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6
#2  0xb74f3c8f in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080532f2 in ah_crap_handler (signum=11) at nsSigHandlers.cpp:134
#4  0xb5b347f7 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:210
#5  <signal handler called>
#6  0xb7e8798d in PL_DHashTableEnumerate (table=0xc9305f4, etor=0xb7e90616 <PL_DHashStubEnumRemove(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*)>, arg=0x0) at pldhash.c:672
#7  0xb626383a in nsTHashtable<nsBaseHashtableET<nsURIHashKey, nsCOMPtr<nsIXBLDocumentInfo> > >::Clear (this=0xc9305f4) at ../../../../dist/include/xpcom/nsTHashtable.h:248
#8  0xb6263861 in nsBaseHashtable<nsURIHashKey, nsCOMPtr<nsIXBLDocumentInfo>, nsIXBLDocumentInfo*>::Clear (this=0xc9305f4) at ../../../../dist/include/xpcom/nsBaseHashtable.h:227
#9  0xb626216d in nsBindingManager::cycleCollection::Unlink (this=0xb651fd44, s=0xc930540) at nsBindingManager.cpp:287
#10 0xb7f11c65 in nsCycleCollectionXPCOMRuntime::Unlink (this=0x8089a00, nodes=@0x80897d0) at nsCycleCollector.cpp:988
#11 0xb7f0f0ba in nsCycleCollector::CollectWhite (this=0xb7f4dd60) at nsCycleCollector.cpp:892
#12 0xb7f0fae2 in nsCycleCollector::Collect (this=0xb7f4dd60) at nsCycleCollector.cpp:1614
#13 0xb7f0fb77 in nsCycleCollector_collect () at nsCycleCollector.cpp:1687
#14 0xb629a48a in nsJSContext::Notify (this=0x9872f88, timer=0xd14d728) at nsJSEnvironment.cpp:3129
#15 0xb7effa81 in nsTimerImpl::Fire (this=0xd14d728) at nsTimerImpl.cpp:386
#16 0xb7effbbe in nsTimerEvent::Run (this=0xacc49b88) at nsTimerImpl.cpp:456
#17 0xb7efa3bc in nsThread::ProcessNextEvent (this=0x80de328, mayWait=1, result=0xbfdaf860) at nsThread.cpp:482
#18 0xb7e947a1 in NS_ProcessNextEvent_P (thread=0x20, mayWait=1) at nsThreadUtils.cpp:225
#19 0xb5b7bbe3 in nsBaseAppShell::Run (this=0x81d1178) at nsBaseAppShell.cpp:153
#20 0xb5be7278 in nsAppStartup::Run (this=0x81cfe38) at nsAppStartup.cpp:218
#21 0x0804dc92 in main1 (argc=3, argv=0xbfdafaf4, nativeApp=<value optimized out>) at nsAppRunner.cpp:1228
#22 0x0804dfef in main (argc=Cannot access memory at address 0x0
) at nsAppRunner.cpp:1722
Keywords: crash, regression
Reporter

Comment 1

13 years ago
Well, I've seen this assertion this time, I haven't paid attention to this.
The *last* thing I did was to close a few tabs.

I've sent a mail, opened another compose window, written some things there and let alone, then I've opened something about 1400 tabs (to increase the memory use), wait some minutes, closed a few. It's not guarented to show up the bug, but happens a lot.
Another thing to mention is that bug 366127 has almost the same steps to reproduce here.

The assertion was:
###!!! ASSERTION: nsTHashtable was not initialized properly.: 'mTable.entrySize', file ../../../dist/include/xpcom/nsTHashtable.h, line 246

Reporter

Comment 2

13 years ago
It's little file, I'm attaching because of the line breaks.

I might to try to crash it tomorrow and provide more info if someone needs it.

If you disable inline spell check in mails you won't suffer from bug 357861, so it could be easier to hit this one.
Posted file Windows equivalent
I just hit this too. I attach a stack trace and memory dump.

I don't know what I was doing at the time, but since there's a timer on the stack, I'm not sure it's relevant ;-)

Note: only mBindingTable and mLoadingDocTable appeared to be corrupt. I was able to jump past the faulting instructions and resume using the suite ;-)
Assignee

Updated

13 years ago
Status: NEW → ASSIGNED
Assignee

Comment 4

13 years ago
Silly thinko on my part. We check the initialization status on ::Traverse but not ::Unlink.
Attachment #250921 - Flags: review?(bugmail)
Comment on attachment 250921 [details] [diff] [review]
fix for crasher in nsBIndingManager::cycleCollection::Unlink

looks good, r/sr=sicking
Attachment #250921 - Flags: superreview+
Attachment #250921 - Flags: review?(bugmail)
Attachment #250921 - Flags: review+
Assignee

Updated

13 years ago
Assignee: nobody → graydon
Status: ASSIGNED → NEW
Assignee

Comment 6

13 years ago
Committed, should be fixed. Reopen if you still see it.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
OS: Linux → All
Hardware: PC → All
Depends on: 368710
Crash Signature: [@ PL_DHashTableEnumerate]
You need to log in before you can comment on or make changes to this bug.