Closed Bug 138259 Opened 23 years ago Closed 22 years ago

_pool_free under hashEnumerate causing many crashes

Categories

(SeaMonkey :: UI Design, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: chris+bugzilla, Assigned: bryner)

Details

(Keywords: crash)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020414 BuildID: 20020417 This crash is happening sporadically all over Mozilla: mail compose, clicking links in browser, etc. I've gotten about 6-7 crashes, none of them apparently reproducable. But they all end with _pool_free under hashEnumerate in the stack. Here's a Mac OSX crash log. I have several more like it. Let me know if you need another (top of stack is similar, rest of stack is somewhat different) Date/Time: 2002-04-18 15:10:33 -0500 OS Version: 10.1.4 (Build 5Q125) Command: Mozilla PID: 19843 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x000000e1 Thread 0: #0 0x0065d020 in 0x65d020 #1 0x0055d330 in _pool_free #2 0x005855d8 in hashEnumerate(PLHashEntry *, int, void *) #3 0x004f9534 in PL_HashTableEnumerateEntries #4 0x00585d48 in nsHashtable::Enumerate(int (*)(nsHashKey *, void *, void *), void *) #5 0x00587e90 in nsSupportsHashtable::_dt(void) #6 0x0331b7b0 in nsPresState::_dt(void) #7 0x0331b574 in nsPresState::Release(void) #8 0x0062986c in nsCOMPtr_base::assign_with_AddRef(nsISupports *) #9 0x03345434 in nsBoxObject::SetDocument(nsIDocument *) #10 0x0287f060 in SetBoxObjectFor__13nsXULDocumentFP13nsIDOMElementP12nsIBoxObje #11 0x028a9624 in nsXULElement::SetDocument(nsIDocument *, int, int) #12 0x028aa088 in nsXULElement::ReplaceChildAt(nsIContent *, int, int, int) #13 0x028a5e5c in ReplaceChild__12nsXULElementFP10nsIDOMNodeP10nsIDOMNodePP10nsI #14 0x005ca9fc in XPTC_InvokeByIndex #15 0x005ca8f0 in XPTC_InvokeByIndex #16 0x0202e674 in 0x202e674 #17 0x02034b0c in XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int, long *, long *) #18 0x01fae99c in js_Invoke #19 0x01fb6a48 in 0x1fb6a48 #20 0x01fae9f4 in js_Invoke #21 0x01fb6a48 in 0x1fb6a48 #22 0x01fae9f4 in js_Invoke #23 0x02027d88 in 0x2027d88 #24 0x020240a4 in CallMethod__14nsXPCWrappedJSFUsPC15nsXPTMethodInfoP17nsXPTCMin #25 0x005cae7c in PrepareAndDispatch #26 0x005cee6c in nsProcessConstructor(nsISupports *, nsID const &, void **) #27 0x03efc940 in NotifyStateListeners__12nsMsgComposeF26TStateListenerNotificat #28 0x03ef7448 in OnStopRequest__27QuotingOutputStreamListenerFP10nsIRequestP11n #29 0x0387552c in nsStreamConverter::OnStopRequest(nsIRequest *, nsISupports *) #30 0x031199a4 in OnStopRequest__25nsImapCacheStreamListenerFP10nsIRequestP11nsI #31 0x020c1368 in nsStorageTransport::nsReadRequest::Process( (void)) #32 0x020c1e98 in OnDataAvailable__Q218nsStorageTransport13nsReadRequestFP10nsIR #33 0x005ca9fc in XPTC_InvokeByIndex #34 0x005ca8f0 in XPTC_InvokeByIndex #35 0x005d31ec in EventHandler(PLEvent *) #36 0x00600d40 in PL_HandleEvent #37 0x00600bac in PL_ProcessPendingEvents #38 0x005a6aac in nsEventQueueImpl::ProcessPendingEvents(void) #39 0x022bea1c in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void) #40 0x022be8c0 in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &) #41 0x00c3bb14 in Repeater::DoRepeaters(EventRecord const &) #42 0x022d4ca8 in nsMacMessagePump::DispatchEvent(int, EventRecord *) #43 0x022d49d0 in nsMacMessagePump::DoMessagePump(void) #44 0x022d434c in nsAppShell::Run(void) #45 0x021f91fc in nsAppShellService::Run(void) #46 0x004d7afc in main1(int, char **, nsISupports *) #47 0x004d853c in main Thread 1: #0 0x7000497c in syscall #1 0x70557600 in BSD_waitevent #2 0x70554b80 in CarbonSelectThreadFunc #3 0x7002054c in _pthread_body Thread 2: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x705593ec in CarbonOperationThreadFunc #3 0x7002054c in _pthread_body Thread 3: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x7003f2b8 in _pthread_cond_wait #3 0x70283ea4 in TSWaitOnConditionTimedRelative #4 0x7027d748 in TSWaitOnSemaphoreCommon #5 0x702c2078 in TimerThread #6 0x7002054c in _pthread_body Thread 4: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x70250ab0 in TSWaitOnCondition #3 0x7027d730 in TSWaitOnSemaphoreCommon #4 0x70243d14 in AsyncFileThread #5 0x7002054c in _pthread_body Thread 5: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x7055b884 in CarbonInetOperThreadFunc #3 0x7002054c in _pthread_body Thread 6: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x70026a2c in _pthread_become_available #3 0x70026724 in pthread_exit #4 0x70020550 in _pthread_body PPC Thread State: srr0: 0x0065d020 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x20000002 lr: 0x00587df4 ctr: 0x00587dd0 mq: 0x00000000 r0: 0x005855d8 r1: 0xbfffd4b0 r2: 0x0010f000 r3: 0x0589ef78 r4: 0x0589ef78 r5: 0x00000000 r6: 0xbfffd5d8 r7: 0x00000001 r8: 0x817c645c r9: 0x00000001 r10: 0x033b6ddc r11: 0xcaabf76f r12: 0x000000e1 r13: 0x00000000 r14: 0x00000036 r15: 0x0072e220 r16: 0x0072e250 r17: 0xbfffee90 r18: 0x005ed500 r19: 0x00003207 r20: 0x00000000 r21: 0x0000001c r22: 0x70004234 r23: 0x700042c8 r24: 0x00000004 r25: 0x000003a4 r26: 0x70002d84 r27: 0x70002e10 r28: 0x00000000 r29: 0xbfffef00 r30: 0x00000000 r31: 0x00000001 Reproducible: Didn't try Steps to Reproduce:
Keywords: crash
ccing brendan; he may know who's a good assignee for this one....
I haven't seen this bug pop up in a long time, so I'll assume it got fixed under a different bug report. Thanks to whoever fixed it! Marking WFM
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reopening. See also my bug 163576.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
The summary is wrong: _pool_free is not causing crashes, something else is passing freed memory (or otherwise corrupting memory) to _pool_free. Trying bryner for box object expertise. /be
Assignee: sgehani → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, my stack on bug 163576 isn't exactly the same; it doesn't include hashEnumerate. Should this be reresolved? (Bug 181111 is another Mac _pool_free bug.)
is this still happening?
I have not been able to reproduce this bug for over a year, so I'm closing it.
Status: NEW → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.