Mozilla crashes on quit if DOM Inspector was used to view stylesheets



16 years ago
12 years ago


(Reporter: bugzilla.1.nrc, Assigned: caillon)



Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030106
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030106

If a stylesheet was viewed in the DOM Inspector, Mozilla will crash upon
quitting.    From the crash log, it looks like nsHashTable is freeing something
it shouldn't.  Seems to be independent of theme.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla
2. Tools -> Web Development -> DOM Inspector
3. File -> Inspect a Window -> (browser window)
4. Change view to Stylesheets using icon in upper left (below Find by Click icon)
5. Close DOM Inspector window.
6. Mozilla -> Quit Mozilla
Actual Results:  
OS X gives "Mozilla quit unexpectedly" dialog and writes a crash log.

Expected Results:  
Exited gracefully.

Mac OS X crash log:

Date/Time:  2003-01-25 14:12:41 -0800
OS Version: 10.2.3 (Build 6G30)
Host:       fatty.local.

Command:    Mozilla
PID:        1447

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x2f726466

Thread 0 Crashed:
 #0   0x02132b50 in 0x2132b50
 #1   0x00253458 in hashFreeEntry(void *, PLHashEntry *, unsigned int)
 #2   0x0025319c in PL_HashTableFinalize(PLHashTable *)
 #3   0x002536cc in nsHashtable::_dt(void)
 #4   0x01e65624 in CSSStyleSheetInner::_dt(void)
 #5   0x01e65840 in CSSStyleSheetInner::RemoveSheet(nsICSSStyleSheet *)
 #6   0x01e6624c in CSSStyleSheetImpl::_dt(void)
 #7   0x01e66680 in CSSStyleSheetImpl::Release(void)
 #8   0x00255d04 in nsSupportsHashtable::ReleaseElement(nsHashKey *, void *, void *)
 #9   0x002534e8 in hashEnumerate(PLHashEntry *, int, void *)
 #10  0x001ca544 in PL_HashTableEnumerateEntries
 #11  0x00253c58 in nsHashtable::Enumerate(int (*)(nsHashKey *, void *, void *),
void *)
 #12  0x00255da0 in nsSupportsHashtable::_dt(void)
 #13  0x02094f70 in nsXULPrototypeCache::_dt(void)
 #14  0x02095074 in nsXULPrototypeCache::Release(void)
 #15  0x002f756c in ReleaseService__16nsServiceManagerFPCcP11nsISupportsP19nsIShut
 #16  0x01ff687c in nsXBLService::_dt(void)
 #17  0x01ff6224 in nsXBLService::Release(void)
 #18  0x027e6c38 in Shutdown(nsIModule *)
 #19  0x00260d7c in nsGenericModule::Shutdown(void)
 #20  0x002605f8 in nsGenericModule::_dt(void)
 #21  0x002606f4 in nsGenericModule::Release(void)
 #22  0x0025d34c in nsDll::Shutdown(void)
 #23  0x002b1ba0 in nsFreeLibrary(nsDll *, nsIServiceManager *, int)
 #24  0x002b1dd0 in nsFreeLibraryEnum(nsHashKey *, void *, void *)
 #25  0x002534e8 in hashEnumerate(PLHashEntry *, int, void *)
 #26  0x001ca544 in PL_HashTableEnumerateEntries
 #27  0x00253c58 in nsHashtable::Enumerate(int (*)(nsHashKey *, void *, void *),
void *)
 #28  0x002b39a0 in nsNativeComponentLoader::UnloadAll(int)
 #29  0x0026f064 in nsComponentManagerImpl::UnloadLibraries(nsIServiceManager *)
 #30  0x00268724 in nsComponentManagerImpl::Shutdown(void)
 #31  0x0029fef0 in NS_ShutdownXPCOM
 #32  0x001a5a64 in main

Thread 1:
 #0   0x9000514c in syscall
 #1   0x90515d6c in BSD_waitevent
 #2   0x9051573c in CarbonSelectThreadFunc
 #3   0x90020d48 in _pthread_body

Thread 2:
 #0   0x9003eaa8 in semaphore_wait_signal_trap
 #1   0x9003e8c4 in _pthread_cond_wait
 #2   0x9051dc30 in CarbonOperationThreadFunc
 #3   0x90020d48 in _pthread_body

Thread 3:
 #0   0x90042688 in semaphore_timedwait_signal_trap
 #1   0x9003e8b4 in _pthread_cond_wait
 #2   0x90233384 in TSWaitOnSemaphoreCommon
 #3   0x9023c170 in TimerThread
 #4   0x90020d48 in _pthread_body

Thread 4:
 #0   0x9003eaa8 in semaphore_wait_signal_trap
 #1   0x9003e8c4 in _pthread_cond_wait
 #2   0x90233368 in TSWaitOnSemaphoreCommon
 #3   0x90248a10 in AsyncFileThread(void*)
 #4   0x90020d48 in _pthread_body

PPC Thread State:
  srr0: 0x02132b50 srr1: 0x0000d030                vrsave: 0x00000000
   xer: 0x20000000   lr: 0x01e61f84  ctr: 0x01e61f50   mq: 0x00000000
    r0: 0x02249dac   r1: 0xbffff150   r2: 0x021e8000   r3: 0x0256a970
    r4: 0x00000001   r5: 0x00000001   r6: 0x00000020   r7: 0x02b475cc
    r8: 0x00000004   r9: 0x00000000  r10: 0x80310060  r11: 0x00000001
   r12: 0x2f726466  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
   r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00000000
   r20: 0xbffffe64  r21: 0xffffffff  r22: 0xbffffc20  r23: 0x00000028
   r24: 0x00000040  r25: 0x02b5a288  r26: 0x00000000  r27: 0x003d58bc
   r28: 0x00000000  r29: 0x00000010  r30: 0x029d6ca0  r31: 0x00000001

Comment 1

16 years ago
does it also happen with 1.3 build (or trunk) ?
Keywords: crash

Comment 2

16 years ago
Created attachment 112652 [details]
Crash log from similar crash using build 2003012503 (trunk)

Comment 3

16 years ago
Tried this on a few versions, here are the results:

1.2.1: same behavior

1.3a: same behavior, EXCEPT on first run: exits fine

trunk (build 2003012503): it takes a bit more work to make it happen.  Open the
window in DOM inspector, select the stylesheets, then click on about a dozen or
so different sheets and rules, then quit.  (I didn't close the DOM inspector in
those tests, but I don't think that will affect anything.)  Also, the crash log
is slightly different (see attachment above).

Comment 4

16 years ago
Also: tried restarting and trashing ~/Library/Mozilla; no effect.

Comment 5

16 years ago
hrm, i actually have some work which would move the stack out of shutdown. but
i'm not sure that'd actually solve the problem.
I've seen talkback stacks like this without any clue that it was related to
Hmm.. the only offhand suspicious thing I see in this code is that
CopyRelevantAttributes has this comment about not needing to addref the atoms...
When I added


to that, the crashes disappeared.

So I suspect someone is forgetting to addref the attr atoms somewhere... (could
we just try moving all this code to nsCOMPtrs in hopes that that would help?)

Comment 8

16 years ago
WorksForMe using FizzillaMach/2003022003. No crash results.
This needs to be retested with tomorrow's build (since bug 163556 was checked in
and the hashtable that was crashing simply does not exist anymore)

Comment 10

16 years ago
I can't reproduce this anymore, should it be marked FIXED?

(p.s. DOM inspector DOMinates)
FIXED, per comment 9
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Core → Other Applications
QA Contact: timeless → dom-inspector
You need to log in before you can comment on or make changes to this bug.