All users were logged out of Bugzilla on October 13th, 2018
I can see this too, on Linux and Win XP. Can be observed nicely by leaving Error console open and closing the main TB window.
Created attachment 609832 [details] Shutdown log from mconley The two exceptions mentioned in the summary for this bug seem to be red herrings - after cleaning them up, TB is still not shutting down smoothly. The variation between my and mconley's logs make me suspect race conditions in the order our components shut down.
Assignee: nobody → irving
Status: NEW → ASSIGNED
I don't know if it is related but for several days now TB does not exit properly (it did before, just spewing those errors into the error console). It seems to crash and waits some time for the debugger (it is a debug build) and then exits. It happens 100% at each close (which I do 100x per day on this test build). This is 'bt' from gdb on linux: #0 0xb7553a8c in nanosleep () from /lib/libc.so.6 #1 0xb75538c4 in sleep () from /lib/libc.so.6 #2 0xb4aa0207 in ah_crap_handler (signum=6) at /var/SSD/TB-hg/mozilla/toolkit/xre/nsSigHandlers.cpp:87 #3 0xb4aa4ccc in nsProfileLock::FatalSignalHandler (signo=6, info=0xbfc4a86c, context=0xbfc4a8ec) at /var/SSD/TB-hg/tbird-bin/mozilla/toolkit/profile/nsProfileLock.cpp:190 #4 <signal handler called> #5 0xb7776749 in raise () from /lib/libpthread.so.0 #6 0xb563299d in Observe (this=0xaf9884c0, aTopic=<optimized out>) at /var/SSD/TB-hg/mozilla/storage/src/mozStorageService.cpp:852 #7 mozilla::storage::Service::Observe (this=0xaf9884c0, aTopic=0xb5e5ec6e "xpcom-shutdown-threads") at /var/SSD/TB-hg/mozilla/storage/src/mozStorageService.cpp:819 #8 0xb5b89bac in nsObserverList::NotifyObservers (this=0xa5a2287c, aSubject=0x0, aTopic=0xb5e5ec6e "xpcom-shutdown-threads", someData=0x0) at /var/SSD/TB-hg/mozilla/xpcom/ds/nsObserverList.cpp:99 #9 0xb5b8a493 in NotifyObservers (someData=0x0, aTopic=0xb5e5ec6e "xpcom-shutdown-threads", aSubject=0x0, this=0xb2d1bb50) at /var/SSD/TB-hg/mozilla/xpcom/ds/nsObserverService.cpp:149 #10 nsObserverService::NotifyObservers (this=0xb2d1bb50, aSubject=0x0, aTopic=0xb5e5ec6e "xpcom-shutdown-threads", someData=0x0) at /var/SSD/TB-hg/mozilla/xpcom/ds/nsObserverService.cpp:138 #11 0xb5b7a60a in mozilla::ShutdownXPCOM (servMgr=0xb7230704) at /var/SSD/TB-hg/mozilla/xpcom/build/nsXPComInit.cpp:585 #12 0xb4a93bcf in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0xb725f10c, __in_chrg=<optimized out>) at /var/SSD/TB-hg/mozilla/toolkit/xre/nsAppRunner.cpp:1104 #13 0xb4a9b1eb in XREMain::XRE_main (this=0xbfc4ade4, argc=4, argv=0xbfc4c074, aAppData=0xb7201180) at /var/SSD/TB-hg/mozilla/toolkit/xre/nsAppRunner.cpp:3885 #14 0xb4a9b3d1 in XRE_main (argc=4, argv=0xbfc4c074, aAppData=0xb7201180, aFlags=0) at /var/SSD/TB-hg/mozilla/toolkit/xre/nsAppRunner.cpp:3939 #15 0x08049e32 in do_main (argv=0xbfc4c074, argc=4, exePath=0xbfc4afb0 "/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/") at /var/SSD/TB-hg/mail/app/nsMailApp.cpp:111 #16 main (argc=4, argv=0xbfc4c074) at /var/SSD/TB-hg/mail/app/nsMailApp.cpp:200
Comment 30 has the following regression range: http://hg.mozilla.org/comm-central/pushloghtml?fromchange=d8c08657b365&tochange=b2e89794570a http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95437bcc43dc&tochange=0e2cc686b07b It's possible it's all part of the same bug but just now manifesting with the indicated regression range, considering that I can consistently reproduce this with my regular profile but not with a brand new (unmodified) profile.
(In reply to IU from comment #5) > Comment 30 has the following regression range: Oops. I meant comment 3.
I fixed the 2 JS error mentioned in comment 0 and the JS error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///Users/ireid/tbird/objdir-comm-central-default/mozilla/dist/DailyDebug.app/Contents/MacOS/components/steelApplication.js :: app_observe :: line 686" data: no] that is in both attachment 608849 [details] and attachment 609832 [details] is gone too (I think it was fixed by bug 750454). I don't see any JS error any more during the shutdown of a trunk debug Thunderbird build, but the shutdown still isn't clean (still lots of warnings, errors, and a large shutdown leak). Not sure what the next step is in cleaning up this mess.
The shutdown error I see in bug 758826 goes away if I uncheck the telemetry pref "submit performance data"
I also do not see any errors any more (I had 3).
Assignee: irving → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.