433977 - 100% CPU on exit from FF3.0pre with Firebug 1.2a28X caused by errors in nsiConsoleService listener

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[John J. Barton]

Using the procedure on 
http://code.google.com/p/fbug/issues/detail?id=677
(it uses that page for the test as well),
I get 100% CPU and no shutdown on Linux. Similar setup fails on Windows. I have windbg on windows.

Firebug's observer of 'quit-application-requested' does fire and print to the OS console.

Any hints on how to track this down or what may cause such things?

Comment 1

[John J. Barton]

A user has posted a stack trace
http://groups.google.com/group/firebug/browse_thread/thread/cd8ad2448df5a2f8

Comment 2

[John J. Barton]

I wonder if update on an extension will clean up components? When the problem started we added a component and then we removed it. But maybe its still in a registry and xpcom is looking for it on exit?

Comment 3

[krishean]

this has happened to me in previous releases of firebug 1.2 alpha on the ff3
nightly, but not all the time. in a28X it seems to happen consistently on
windows

on a clean profile with only firebug installed firefox will fail to
shutdown/restart

Comment 4

[John J. Barton]

I think this is the stack from the thread that is looping

js3250!js_ExpandErrorArguments+0x73 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jscntxt.c @ 1025]
js3250!js_ReportErrorNumberVA+0x98 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jscntxt.c @ 1187]
js3250!JS_ReportErrorNumber+0x22 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jsapi.c @ 5492]
js3250!js_ReportIsNotDefined+0x18 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jscntxt.c @ 1247]
js3250!js_Interpret+0x46cd5
js3250!js_Invoke+0x37e [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jsinterp.c @ 1313]
xul!nsXPCWrappedJSClass::CallMethod+0x5c0 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp @ 1524]
xul!nsXPCWrappedJS::CallMethod+0x38 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp @ 560]
xul!PrepareAndDispatch+0xe7 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 114]
xul!SharedStub+0x16 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 142]
xul!NS_InvokeByIndex_P+0x27 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp @ 102]
xul!nsProxyObjectCallInfo::Run+0x1d [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\proxy\src\nsproxyevent.cpp @ 183]
xul!nsThread::ProcessNextEvent+0x29a [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\threads\nsthread.cpp @ 510]
xul!NS_ProcessPendingEvents_P+0x29 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\xpcom\build\nsthreadutils.cpp @ 180]
xul!nsBaseAppShell::Run+0x59 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\widget\src\xpwidgets\nsbaseappshell.cpp @ 172]
xul!nsAppStartup::Run+0x1e [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\toolkit\components\startup\src\nsappstartup.cpp @ 182]
xul!XRE_main+0xdba [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\toolkit\xre\nsapprunner.cpp @ 3174]
firefox!wmain+0x213 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\toolkit\xre\nswindowswmain.cpp @ 87]
firefox!__tmainCRTStartup+0x152 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\crtexe.c @ 591]
kernel32!BaseProcessStart+0x23

Comment 5

[John J. Barton]

I cleaned up the shutdown code and tried a clean profile, no better.

Comment 6

[Shawn Wilsher :sdwilsh]

Getting a JS stack would probably be useful here too.

Comment 7

[John J. Barton]

(In reply to comment #6)
> Getting a JS stack would probably be useful here too.
> 
Firebug has shutdown jsd and returned from QuitApplicationObserver
observerService.addObserver(QuitApplicationObserver, "quit-application", false); 

Comment 8

[John J. Barton]

Looks like its trying to report an error concerning "FirebugContext" (I can see that string and C++ functions like js_ExpandErrorArguments) as I step. I can't get the C++ source to show in windbg however.

Comment 9

[John J. Barton]

Yes, its trying to report "FirebugContext is not defined"

Comment 10

[John J. Barton]

Ok it must be that I have to take the error observer out soon. The problem is on line 102 of errors.js 
    // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    // extends ConsoleObserver

    observe: function(object)
    {
        try
        {
            var context = FirebugContext;
Since FirebugContext is not in what ever weird scope we are no in, it gives undefined, which reports the error and triggers the observer again.

Comment 11

[Justin Wood (:Callek)]

ok, seems likely it is due to Firebug code, removing blocking request. (Firebug itself is blocked in Bug 411814)

Comment 12

[John J. Barton]

I edited the title and removed this as a blocker for Firebug since 1.2a30 does not show the loop on windows. 

In my opinion this is a bug in the platform in that a pure javascript application shouldn't be able to cause this much trouble. For example, following quit-application, the error listeners could be disabled and errors forced out to the OS console (on OS that support such).  Or errors in the listeners could be resolve in another fashion, alert, OS console, files.

Comment 13

[John J. Barton]

No sense making this a priority since its not going to be fixed.

Comment 14

[Rob Campbell [:rc] (:robcee)]

a minimal testcase would help this get fixed.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Closing this as incomplete due to inactivity and the lack of a reproducible test case. Feel free to reopen the bug if there's a testcase that still reproduces the issue.