345829 - Profile Roaming password dialog on Exit causes 100% CPU usage

Status: RESOLVED WONTFIX

(Core Graveyard :: Profile: Roaming, defect)

Description

[Frank Wein [:mcsmurf]]

To reproduce:
1. Enable Roaming for your profile in SeaMonkey, do not save the password (I used a FTP account here)
2. Exit SeaMonkey and watch CPU usage when the dialog which asks for the FTP password comes up

Actual Results:
100% CPU usage will be observed.

Stacktrace when the 100% CPU usage occours:
 	USER32.DLL!77e2c537() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for USER32.DLL]	
 	USER32.DLL!77e2c4f7() 	
 	USER32.DLL!77e2c624() 	
>	gkwidget.dll!nsAppShell::ProcessNextNativeEvent(int mayWait=0)  Line 142 + 0x56 bytes	C++
 	gkwidget.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=0)  Line 137	C++
 	gkwidget.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x007e6f48, int mayWait=1, unsigned int recursionDepth=1)  Line 231 + 0xc bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012db90)  Line 473	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x007e6f48, int mayWait=1)  Line 225 + 0xd bytes	C++
 	appshell.dll!nsXULWindow::ShowModal()  Line 402 + 0xb bytes	C++
 	appshell.dll!nsContentTreeOwner::ShowAsModal()  Line 503	C++
 	embedcomponents.dll!nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow * aParent=0x0caba6f0, const char * aUrl=0x01174644, const char * aName=0x011745d8, const char * aFeatures=0x011747c8, int aDialog=1, nsIArray * argv=0x0ca91c58, int aCalledFromJS=0, nsIDOMWindow * * _retval=0x0012de74)  Line 859	C++
 	embedcomponents.dll!nsWindowWatcher::OpenWindow(nsIDOMWindow * aParent=0x0caba6f0, const char * aUrl=0x01174644, const char * aName=0x011745d8, const char * aFeatures=0x011747c8, nsISupports * aArguments=0x0ca2e798, nsIDOMWindow * * _retval=0x0012de74)  Line 413 + 0x24 bytes	C++
 	embedcomponents.dll!nsPromptService::DoDialog(nsIDOMWindow * aParent=0x02624958, nsIDialogParamBlock * aParamBlock=0x0ca2e798, const char * aChromeURL=0x01174644)  Line 659	C++
 	embedcomponents.dll!nsPromptService::PromptPassword(nsIDOMWindow * parent=0x0caba6f0, const unsigned short * dialogTitle=0x0ca1e4d8, const unsigned short * text=0x020563b8, unsigned short * * password=0x0012e008, const unsigned short * checkMsg=0x0ca90b98, int * checkValue=0x0012e028, int * _retval=0x0012e038)  Line 539	C++
 	xpcom_core.dll!XPTC_InvokeByIndex(nsISupports * that=0x0012e188, unsigned int methodIndex=1237120, unsigned int paramCount=33620912, nsXPTCVariant * params=0x0125174f)  Line 102	C++
 	js3250.dll!JS_SuspendRequest(JSContext * cx=0x00eabf44)  Line 907 + 0x6 bytes	C
 	xpc3250.dll!nsXPConnect::Release()  Line 48 + 0x10 bytes	C++
 	xpc3250.dll!XPCCallContext::~XPCCallContext()  Line 358 + 0xd bytes	C++
 	xpc3250.dll!XPC_WN_OnlyIWrite_PropertyStub(JSContext * cx=0x01fd90b0, JSObject * obj=0x0000000a, long idval=7, long * vp=0x0012dfd8)  Line 511 + 0x1e bytes	C++
 	xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD)  Line 2162 + 0x19 bytes	C++
 	xpc3250.dll!XPC_WN_CallMethod(JSContext * cx=0x0cb49200, JSObject * obj=0x00e90ec8, unsigned int argc=6, long * argv=0x0ca59d54, long * vp=0x0012e250)  Line 1450 + 0xa bytes	C++
 	js3250.dll!js_Invoke(JSContext * cx=0x0cb49200, unsigned int argc=6, unsigned int flags=0)  Line 1349 + 0x11 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x0cb49200, unsigned char * pc=0x0c17e5c8, long * result=0x0012e4cc)  Line 4086	C
 	js3250.dll!js_Invoke(JSContext * cx=0x0cb49200, unsigned int argc=5, unsigned int flags=2)  Line 1368 + 0xc bytes	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x0bf7ac80, unsigned short methodIndex=5, const nsXPTMethodInfo * info=0x0261e5d8, nsXPTCMiniVariant * nativeParams=0x0012e6ec)  Line 1418 + 0x10 bytes	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=5, const nsXPTMethodInfo * info=0x0261e5d8, nsXPTCMiniVariant * params=0x0012e6ec)  Line 478	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x0bf7ac80, unsigned int methodIndex=5, unsigned int * args=0x0012e7a8, unsigned int * stackBytesToPop=0x0012e798)  Line 117 + 0x15 bytes	C++
 	xpcom_core.dll!SharedStub()  Line 147	C++
 	necko.dll!nsFtpState::S_pass()  Line 812 + 0x4c bytes	C++

As far as I could see the stack up to nsThread::ProcessNextEvent is always the same, but everything above that frame changes. So it seems like there's something like a flood of new events coming in?

Comment 1

[Frank Wein [:mcsmurf]]

After doing some testing with nightlies it seems this bug here is probably caused by the thread manager landing (Bug 326273). Maybe something is wrong with the threading in the roaming code (see the code comment under http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/extensions/sroaming/src/Stream.cpp&rev=1.3#180 )?

Comment 2

[Wayne Mery (:wsmwk)]

hmm. Do you still see this?  The bug is neither marked regression nor blocking bug 326273.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> hmm. Do you still see this?  The bug is neither marked regression nor
> blocking bug 326273.

Comment 4

[Frank Wein [:mcsmurf]]

Oh heh, very old bug :) WONTFIX I guess since Roaming code is long gone and probably won't reappear anytime soon.