Closed Bug 346352 Opened 18 years ago Closed 18 years ago

TB does not shutdown after updates are downloaded

Categories

(Thunderbird :: Installer, defect)

Other
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bob.lord, Assigned: mscott)

References

Details

For about a week, I've been downloading the nightly updates to TB2.0.  The download seems to work.  However, when I'm told I need to restart TB, the UI goes away as expected.  However the TB process remains active.

So I kill the processes and restart TB.  It applies the updates and I am able to use the new code.

I'm running Fedora Core 5, and running TB version 2 alpha 1 (20060728).

Also, I often crash when restarting the client.  You might want to search for bug reports tied to bob.lord@gmail.com.
I looked at a couple of your stacks. They look like the following. Looks like the PSM thread is trying to clean up on exit, and then we crash down in the DOM, triggered by js garbage collection.

libc.so.6 + 0x65c74 (0x00b5ec74)
PL_DHashAllocTable()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/xpcom/build/pldhash.c, line 90]
ChangeTable()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/xpcom/build/pldhash.c, line 495]
PL_DHashTableOperate()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/xpcom/build/pldhash.c, line 581]
ClassifyWrapper()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 5240]
PL_DHashTableEnumerate()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/xpcom/build/pldhash.c, line 684]
nsDOMClassInfo::BeginGCMark()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 5307]
nsDOMClassInfo::MarkReachablePreservedWrappers()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 5136]
nsDOMGCParticipantSH::Mark()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 6912]
XPC_WN_Helper_Mark()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1032]
js_Mark()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsobj.c, line 4597]
MarkGCThingChildren()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 1817]
MarkGCThingChildren()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 1804]
MarkGCThingChildren()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 1804]
MarkGCThingChildren()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 1804]
js_MarkGCThing()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 2184]
gc_root_marker()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 2225]
JS_DHashTableEnumerate()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsdhash.c, line 675]
js_GC()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 2558]
js_ForceGC()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsgc.c, line 2252]
js_DestroyContext()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jscntxt.c, line 389]
JS_DestroyContext()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/jsapi.c, line 953]
XPCJSContextStack::~XPCJSContextStack()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp, line 62]
XPCPerThreadData::Cleanup()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp, line 389]
XPCPerThreadData::~XPCPerThreadData()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp, line 397]
xpc_ThreadDataDtorCB()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp, line 429]
_PR_DestroyThreadPrivate()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/nsprpub/pr/src/threads/prtpd.c, line 266]
_pt_thread_death()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/nsprpub/pr/src/pthreads/ptthread.c, line 816]
PR_JoinThread()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/nsprpub/pr/src/pthreads/ptthread.c, line 599]
nsPSMBackgroundThread::requestExit()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/security/manager/ssl/src/nsPSMBackgroundThread.cpp, line 98]
nsNSSComponent::Observe()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/security/manager/ssl/src/nsNSSComponent.cpp, line 1969]
nsObserverService::NotifyObservers()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/xpcom/ds/nsObserverService.cpp, line 231]
nsXREDirProvider::DoShutdown()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/toolkit/xre/nsXREDirProvider.cpp, line 830]
ScopedXPCOMStartup::~ScopedXPCOMStartup()  [/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/toolkit/xre/nsAppRunner.cpp, line 552]
Bob, do you switch between 2.0 builds and older/newer builds? That will cause us to shutdown and restart silently when you try to run - your crashes look to be actually on shutdown, before the restart.
I filed Bug 346355 to keep track of the 2nd issue in this bug report, regarding the crash. 
(In reply to comment #2)
> Bob, do you switch between 2.0 builds and older/newer builds? That will cause
> us to shutdown and restart silently when you try to run - your crashes look to
> be actually on shutdown, before the restart.
> 

I only run the mozilla1.8 nightly builds.  Interestingly, I tried to shutdown TB just now, and it would not stop even though there was no update.  So perhaps this isn't an auto-update issue at all.

I do enable FIPS mode.  Might that be a factor with this problem?  Adding Wan-Teh to the cc list. 

I need to see if I can reproduce this on my Windows machine at home.
do you have an imap account configured to empty trash or compact the inbox on exit?
(In reply to comment #5)
> do you have an imap account configured to empty trash or compact the inbox on
> exit?

I just checked: No. And No. 

I am using SSL/IMAP if that matters.
This is seemingly the exact same stack Myk reported in bug 344277 comment 1 (except he has symbols for libc.so.6). 

In bug 344277 comment 6 Myk says that dbaron thinks this crash is caused by bug 335018. The fix for that bug just landed on the 1.8 branch this afternoon, so it'd probably be worth seeing if you can reproduce this tomorrow or in the days to come.
Depends on: 346355
Do you still run into this bug?

Could this be related to bug 176501?
This bug has gone away.  OK to mark WORKSFORME.

cool
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.