154753 - nsExceptionService ignoring thread destruction after shutdown [@ nsExceptionService::DoDropThread]

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect, P3)

Description

[timeless]

w32, w2k, cvs, trunk, opt profile build from today

steps:
delete components\compreg.dat
run regxpcom

watch the output at the end.

This is what i saw:
nNCL: registering deferred (0)
WARNING: nsExceptionService ignoring thread destruction after shutdown, file
f:\build\mozilla\xpcom\base\nsExceptionService.cpp, line 191
JS API usage error: 1 contexts left in runtime upon JS_DestroyRuntime.
JS engine warning: 1 atoms remain after destroying the JSRuntime.
                   These atoms may point to freed memory. Things reachable
                   through them have not been finalized.
JS engine warning: leaking GC root 'res->input' at 0042E470
JS engine warning: 1 GC root remains after destroying the JSRuntime.
                   This root may point to freed memory. Objects reachable
                   through it have not been finalized.
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0',
file f:\build\mozilla\xpcom\build\nsXPComInit.cpp, line 648

Here's the call stack:
nsExceptionService::ThreadDestruct(void * 0x0047ce70) line 191
PR_SetThreadPrivate(unsigned int 4, void * 0x00000000) line 207 + 16 bytes
nsExceptionService::Shutdown() line 206 + 15 bytes
nsExceptionService::Observe(nsExceptionService * const 0x0047d0b4, nsISupports *
0x00416344, const char * 0x101060c0, const unsigned short * 0x00000000) line 286
nsObserverService::NotifyObservers(nsObserverService * const 0x0041aeb0,
nsISupports * 0x00416344, const char * 0x101060c0, const unsigned short *
0x00000000) line 213
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 583
main(int 1, char * * 0x004140a0) line 202 + 8 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()

And here's a summary of what's happening:

void nsExceptionService::Shutdown()
{
  mProviders.Reset();
  if (lock) {
    DropAllThreads();
    PR_DestroyLock(lock);
    lock = nsnull;
  }
  PR_SetThreadPrivate(tlsIndex, nsnull); // <- we're here and this calls
PR_SetThreadPrivate which calls the callback
}

void nsExceptionService::ThreadDestruct( void *data )
{
  if (!lock) {
    NS_WARNING("nsExceptionService ignoring thread destruction after shutdown");
    return;
  }
  DropThread( (nsExceptionManager *)data );
}


So it's:

if (lock)
lock = 0
}
if (!lock){
ASSERT()
return;
}

Comment 1

[timeless]

Attachment: patch [Backout: Comment 5]

Comment 2

[Doug Turner (:dougt)]

Comment on attachment 89523 [details] [diff] [review]
patch
[Backout: Comment 5]

and the ~() calls shutdown.

Maybe you should move mProviders.Reset() under the lock check so that it isn't
called twice at shutdown.

Comment 3

[Simon Fraser [no longer active]]

Comment on attachment 89523 [details] [diff] [review]
patch
[Backout: Comment 5]

sr=sfraser

Comment 4

[timeless]

fixed

Comment 5

[Akkana Peck]

This caused a crash at shutdown on linux, and an orange Tinderbox, so it's been
backed out.  Reopening the bug.

Here's the stack trace:
#0  0x420b4b31 in nanosleep () from /lib/i686/libc.so.6
#1  0x420b49b1 in sleep () from /lib/i686/libc.so.6
#2  0x080675d8 in ah_crap_handler (signum=11) at nsSigHandlers.cpp:144
#3  0x4199a4c5 in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileAccess.cpp:1668
#4  0x40326f75 in pthread_sighandler () from /lib/i686/libpthread.so.0
#5  <signal handler called>
[ ... garbage after this ]

Comment 6

[timeless]

tinus provided a talkback stack TB8166604H
and a gdb stack:
#0  0x40174f6a in nsExceptionService::DoDropThread () from ./libxpcom.so
#1  0x40174fab in nsExceptionService::DropThread () from ./libxpcom.so
#2  0x40174ab7 in nsExceptionService::ThreadDestruct () from ./libxpcom.so
#3  0x401d74c9 in PR_SetThreadPrivate () from ./libnspr4.so
#4  0x40174af7 in nsExceptionService::Shutdown () from ./libxpcom.so
#5  0x40174de0 in nsExceptionService::Observe () from ./libxpcom.so
#6  0x4012cfe6 in nsObserverService::NotifyObservers () from ./libxpcom.so
#7  0x40124da0 in NS_ShutdownXPCOM () from ./libxpcom.so
#8  0x080517ec in main ()
#9  0x404f5316 in __libc_start_main (main=0x80516a8 <main>, argc=1,
    ubp_av=0xbffff9e4, init=0x804c2bc <_init>, fini=0x8052cb8 <_fini>,
    rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffff9dc)
    at ../sysdeps/generic/libc-start.c:129

unfortunately talkback doesn't have line numbers for linux atm.

Ok, i finally became alert enough to figure out what's probably going on

see bug 83508 comment 5. there's an NS_ABORT_IF_FALSE.

markh: ideas?

Comment 7

[Olivier Cahagne]

Also caused regression when sending e-mails, see bug 156630.

Comment 8

[greer]

This crasher is top of the Talkback Trunk heap for Linux. -> topcrash

Comment 9

[Jan Carpenter]

2 incidents in the database from august of 2002.  Marking fixed.

Comment 10

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

The fix for this bug was backed out and I still see the crash happen at startup
with a LindowsOS4 (debian), gcc/g++ 2.95.4. Reopening.

Comment 11

[Wayne Mery (:wsmwk)]

only 3 crashes on talkback

TB38524982 MAC
nsExceptionService::DoDropThread()  [mozilla/xpcom/base/nsExceptionService.cpp, line 334]
nsExceptionService::DoDropThread()  [mozilla/xpcom/base/nsExceptionService.cpp, line 328]
XPCThrower::BuildAndThrowException()  [mozilla/js/src/xpconnect/src/xpcthrower.cpp, line 830]
XPCThrower::ThrowBadResult()  [mozilla/js/src/xpconnect/src/xpcthrower.cpp, line 145]
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()  [mozilla/js/src/xpco]
XPC_WN_CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3944]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1455]
PrepareAndDispatch()  [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ppc_rhaps]
SharedStub()
nsObserverService::NotifyObservers()  [mozilla/xpcom/ds/nsObserverService.cpp, line 848]
nsXREDirProvider::DoStartup()  [mozilla/db/sqlite3/src/pragma.c, line 848]
XRE_main()  [mozilla/toolkit/xre/nsAppRunner.cpp, line 97]
_start()   start()


and 2 windows, which are identical
TB38587533
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-Release/WINNT_5.2_Depend/mozilla/xpcom/base/nsExceptionService.cpp, line 334
Stack Trace 	
nsExceptionService::DoDropThread  [mozilla/xpcom/base/nsExceptionService.cpp, line 334]
NS_ShutdownXPCOM_P  [mozilla/xpcom/build/nsXPComInit.cpp, line 814]
ScopedXPCOMStartup::~ScopedXPCOMStartup  [mozilla/toolkit/xre/nsAppRunner.cpp, line 762]
main  [mozilla/browser/app/nsBrowserApp.cpp, line 61]
KERNEL32.dll + 0x289d5 (0x794789d5)

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

A clean Mac trunk Thunderbird debug build outputs the following on shutdown:

WARNING: nsExceptionService ignoring thread destruction after shutdown: file /Users/skywalker/Desktop/Mozilla/cvs/mozilla/xpcom/base/nsExceptionService.cpp, line 191

Comment 13

[Serge Gautherie (:sgautherie)]

<http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1217484420.1217485284.24505.gz&fulltext=1>
{{
Linux nye Depend bloat on 2008/07/30 23:07:00

WARNING: nsExceptionService ignoring thread destruction after shutdown: file /home/andrew/tbox/SeaMonkey-Debug/Linux_2.6.22.14-72.fc6_Depend/src/mozilla/xpcom/base/nsExceptionService.cpp, line 194
}}

And
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/2008073018 SeaMonkey/2.0a1pre] (home made) (W2Ksp4)

Comment 14

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/20080812190058 Minefield/3.1a2pre] (home, debug) (W2Ksp4)

Fwiw, lots of tests in |make check| show this warning.

Comment 15

[Serge Gautherie (:sgautherie)]

(In reply to comment #14)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080927200111 Minefield/3.1b1pre] (home, debug default) (W2Ksp4)

'XPIDL tests' and '/toolkit/components/feeds/test' reftests reports this warning.

Comment 16

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090409 Minefield/3.6a1pre] (home, debug+options) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/cb053a66c9ed)

Comment 17

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4pre) Gecko/20091007
Shiretoko/3.5.4pre] (home, debug) (W2Ksp4)
(http://hg.mozilla.org/releases/mozilla-1.9.1/rev/53e39a465d7b)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090817
Minefield/3.7a1pre] (home, debug default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/432fb39d5655)

TestCookie reports this.

Comment 18

[Robert Kaiser]

I see 9 crashes over the last 4 weeks, including cases in Firefox 12 and 13. Any plans to revive that patch and drive it into the tree?

Comment 19

[Scoobidiver (away)]

The topcrash- keyword is not actively maintained and pollutes queries with topcrash.

Comment 20

[Benjamin Smedberg]

Can we just use a windbg script to collect a minidump of the process?

Comment 21

[Benjamin Smedberg]

Oops, wrong bug.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reopening because crash bugs **with testcases** should not be resolved **as WONTFIX** based on queries of crash-stats.  Other resolutions may be appropriate for other reasons.

(Crash signatures are not the same as bug identity; they're merely a search aid to find and group similar crashes.  The bug may still be present, but the signature may have changed slightly, or the bug may even still be present with the same signature but there are simply no recent reports of crashes in that function.)

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:nika, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 25

[Andrew McCreight [:mccr8]]

nsExceptionService doesn't appear to exist any more.