Profile Roaming password dialog on Exit causes 100% CPU usage

RESOLVED WONTFIX

Status

Core Graveyard
Profile: Roaming
--
major
RESOLVED WONTFIX
12 years ago
2 years ago

People

(Reporter: mcsmurf, Unassigned)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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?
(Reporter)

Comment 1

12 years ago
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

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

Comment 3

4 years ago
(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.
Flags: needinfo?(bugzilla)
(Reporter)

Comment 4

4 years ago
Oh heh, very old bug :) WONTFIX I guess since Roaming code is long gone and probably won't reappear anytime soon.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(bugzilla)
Resolution: --- → WONTFIX
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.