Closed Bug 285924 Opened 20 years ago Closed 20 years ago

on quit, tbird takes 99% cpu and process never quits

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: sspitzer, Assigned: mscott)

Details

on quit, tbird takes 99% cpu and process never quits

I'm using version 1.0+ (20050312)
i haven't been able to reproduce this yet using the 03/12 installer build. 
> i haven't been able to reproduce this yet using the 03/12 installer build. 

here's what I did to reproduce it:

1) start up
2) new message, hit the [x] in the upper right to close the new message
3) hit the [x] in the upper right of the 3 pane to close the 3 pane
4) cpu pinged.

let me see if I can get a stack.
it's an optimized build, so the stack isn't very useful.

but maybe you see something that looks odd:

>	thunderbird.exe!0040b8ca() 	
 	thunderbird.exe!0040b905() 	
 	thunderbird.exe!00416158() 	
 	nspr4.dll!60178460() 	
 	nspr4.dll!601770fc() 	
 	js3250.dll!600abc9f() 	
 	nspr4.dll!60178455() 	
 	nspr4.dll!60174832() 	
 	js3250.dll!6009594c() 	
 	js3250.dll!60099021() 	
 	js3250.dll!60091e77() 	
 	thunderbird.exe!0050f135() 	
 	thunderbird.exe!0050f088() 	
 	thunderbird.exe!0050f2b0() 	
 	xpcom_core.dll!603310b3() 	
 	thunderbird.exe!006a1a0b() 	
 	thunderbird.exe!006a1db9() 	
 	thunderbird.exe!006a1d7a() 	
 	thunderbird.exe!006a1b7a() 	
 	xpcom_core.dll!60331090() 	
 	thunderbird.exe!006569b8() 	
 	thunderbird.exe!00657743() 	
 	xpcom_core.dll!6034042c() 	
 	thunderbird.exe!006556be() 	
 	thunderbird.exe!006554cb() 	
 	xpcom_core.dll!60331090() 	
 	thunderbird.exe!00586f9c() 	
 	thunderbird.exe!0058035d() 	
 	thunderbird.exe!00587658() 	
 	thunderbird.exe!0051cfc9() 	
 	js3250.dll!600bb574() 	
 	js3250.dll!600ac286() 	
 	js3250.dll!600abc69() 	
 	js3250.dll!60099082() 	
 	js3250.dll!60091e77() 	
 	thunderbird.exe!0040f1c8() 	
 	thunderbird.exe!0040f194() 	
 	thunderbird.exe!0040f960() 	
 	thunderbird.exe!0040b839() 	
 	ntdll.dll!7c91056d() 	
 	msvcrt.dll!77c2c2de() 	
 	msvcrt.dll!77c2c2e3() 	
 	thunderbird.exe!004451c0() 	
 	thunderbird.exe!0040b794() 	
 	thunderbird.exe!0040b650() 	
 	thunderbird.exe!004844f8() 	
 	xpcom_core.dll!6033275d() 	
 	xpcom_core.dll!60332550() 	
 	xpcom_core.dll!603310b3() 	
 	xpcom_core.dll!60356ee1() 	
 	xpcom_core.dll!6034042c() 	
 	xpcom_core.dll!60356f40() 	
 	xpcom_core.dll!60356f1b() 	
 	xpcom_core.dll!60352834() 	
 	xpcom_core.dll!603348a0() 	
 	thunderbird.exe!0040150c() 	
 	thunderbird.exe!00402039() 	
 	ntdll.dll!7c9106ab() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c910732() 	
 	ntdll.dll!7c911538() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c9106ab() 	
 	ntdll.dll!7c9105c8() 	
 	ntdll.dll!7c910551() 	
 	ntdll.dll!7c9105c8() 	
 	ntdll.dll!7c910551() 	
 	ntdll.dll!7c9105c8() 	
 	ntdll.dll!7c910551() 	
 	ntdll.dll!7c91056d() 	
 	ntdll.dll!7c911538() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c90d4ea() 	
 	ntdll.dll!7c9180ff() 	
 	ntdll.dll!7c911bff() 	
 	ntdll.dll!7c91825d() 	
 	ntdll.dll!7c911538() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c91056d() 	
 	ntdll.dll!7c911538() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c9106eb() 	
 	msvcrt.dll!77c2c42e() 	
 	xpcom_core.dll!6036a179() 	
 	xpcom_core.dll!6036a1e8() 	
 	ntdll.dll!7c917bb0() 	
 	ntdll.dll!7c911b09() 	
 	msvcrt.dll!77c2c3c9() 	
 	msvcrt.dll!77c2c024() 	
 	msvcrt.dll!77c2c02d() 	
 	thunderbird.exe!00401012() 	
 	thunderbird.exe!0040102e() 	
 	thunderbird.exe!00979394() 	
 	kernel32.dll!7c816d4f() 	
 	kernel32.dll!7c8399f3() 	

interesting, if I don't do the "new compose window step" this doesn't happen.
specific steps to reproduce this:

1) start up tbird
2) new message, hit the [x] in the upper right to close the new message
3) hit ok, for "don't save" the message
4) hit the [x] in the upper right of the 3 pane to close the 3 pane
5) cpu pinged.

I'll go see if 3/12 has this issue.
worksforme now, with 3/13 (odd.  do my steps cause 3/12 to ping the cpu for you?)

sorry for the noise.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
re-opening, I just saw the freeze again when I quit tbird, 3/13 bits.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
so far i can't make a debug build do this.

I've seen it a couple times in optimized builds though. 

I do see some new unusual errors when sending mail that may be related:

CopyListener: SUCCESSFUL ON THE COPY OPERATION!
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "'[JavaScript Error: "gMsgCompose has no properties" {file: "chrom
e://messenger/content/messengercompose/MsgComposeCommands.js" line: 156}]' when
calling method: [nsIMsgComposeStateListener::ComposeProcessDone]"  nsresult: "0x
80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "<unknown>"  d
ata: yes]
************************************************************
nsMsgComposeSendListener: Success on the message copy operation!

ComposeUnload from XUL
WARNING: nsComposerCommandsUpdater::SelectionIsCollapsed - no domSelection, file
 c:/build/trees/tbirddbg/mozilla/editor/composer/src/nsComposerCommandsUpdater.c
pp, line 386
###!!! ASSERTION:
XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.

I'm sure it's unrelated but we need to fix these errors anyway.

It looks like the compose window is getting told to close itself twice. 

1) Once when the IMAP url finishes running, ImapFolder::OnCopyCompleted ends up
calling the copy service which ends up calling CopyListener::OnStopCopy.

2) The second time happens when the imap mail folder calls
::CopyNextStreamListener. The copy listener still has a valid pointer to the
compose send object so we tell it to close again, here's the stack for this case:

nsMsgCompose::NotifyStateListeners(nsMsgCompose * const 0x045ba7b8,
TStateListenerNotification eComposeProcessDone, unsigned int 0) line 3619
nsMsgComposeSendListener::OnStopCopy(nsMsgComposeSendListener * const
0x053e4050, unsigned int 0) line 2972
nsMsgComposeAndSend::NotifyListenerOnStopCopy(nsMsgComposeAndSend * const
0x034b4b50, unsigned int 0) line 3989
CopyListener::OnStopCopy(CopyListener * const 0x05480180, unsigned int 0) line 155
nsImapMailFolder::CopyNextStreamMessage(nsImapMailFolder * const 0x0313c6f0, int
1, nsISupports * 0x054802c8) line 6045

I haven't seen this in a very long time. Marking works for me. Feel free to
re-open Seth if you start seeing it again.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
verified.  I have been upgrading to the trunk bits as it comes out, and I have
not see it either.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.