597148 - Web Console can cause scripts in the page to throw

Status: RESOLVED WORKSFORME

(DevTools :: General, defect)

Description

[Mihai Sucan [:msucan]]

STR:

0. Make sure you have the Error console enabled. (about:config#devtools.errorconsole.enabled)

1. Open the Error console.
2. Open www.robodesign.ro.
Notice no errors are shown, nothing is broken.

3. Open the Web Console.
4. Refresh the page (F5 or whatever).
Notice all network requests are nicely logged by the Web Console. Also, no exceptions are shown in the Error console, nothing bad.

5. Press F5 and quickly press Ctrl-Shift-K (the shortcut to toggle the Web Console), hold the keys down or press them as fast as you can while the page loads. Rinse and repeat this step a few times (the refresh and quick toggling of the Web Console).

Expected result: the web page loads nicely while the Web Console opens and closes like a beserk.

Actual result: the Error console shows:

Error: Cannot get outputNode by id
Source File: resource://gre/modules/HUDService.jsm
Line: 4621

Error: myAddEvent is not a function
Source File: http://www.robodesign.ro/js/index.js
Line: 1446

The first error is clear: it comes from the window.onerror handler of the HUDService which is not removed and which tries to show exceptions in the Web Console which is not open. This is bug 597136.

The second error is the point of this report: myAddEvent is not a function?? If you look in the JavaScript file, it's always defined. Why does it break now? Why does the code throw?

I once got google-analytics.com/ga.js to throw: Math.random is not a function (or undefined, I can't remember exactly, seen this only once). Weird.

Comment 1

[David Dahl :ddahl]

we need a very clear, repeatable test case for this first and foremost.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #0)
> The first error is clear: it comes from the window.onerror handler of the
> HUDService which is not removed and which tries to show exceptions in the Web
> Console which is not open. This is bug 597136.
> 
> The second error is the point of this report: myAddEvent is not a function?? 

Can't the second be caused by the first? An exception early in script execution can mean cause a function defined later in the file won't be.

Comment 3

[Mihai Sucan [:msucan]]

(In reply to comment #2)
> (In reply to comment #0)
> > The first error is clear: it comes from the window.onerror handler of the
> > HUDService which is not removed and which tries to show exceptions in the Web
> > Console which is not open. This is bug 597136.
> > 
> > The second error is the point of this report: myAddEvent is not a function?? 
> 
> Can't the second be caused by the first? An exception early in script execution
> can mean cause a function defined later in the file won't be.

Agreed, but take into consideration that the window.onerror code is an event handler that executes in a different context, asynchronously from the main code (index.js) from the page.

Additionally, the window.onerror event handler never really executes, unless there's an exception in the first place.

The way I see it, at the moment, is: the second triggers the first, because the exception is first thrown, then the window.onerror event handler executes, which also throws.

Still, I am not ruling out any possible weirdness, related to the onerror event handler somehow causing errors in the web page.

Anyhow, as David said, I must prepare a test case for this bug.

Comment 4

[Mihai Sucan [:msucan]]

Attachment: mochitest

Mochitest that always reproduces the failure.

The situation:

- one html file
   - which loads multiple stylesheets
  - which include background-images that match elements in the page
  - includes <img> elements
  - includes an external script:
function foobar() {
  return "hello world!";
}

foobar();

- script fails to execute: foobar is not a function. It happens only if during this time the Web Console opens/closes really fast, and only if there are enough network requests in the page. Somehow, simply having image requests is not enough - I had to include the stylesheets.

This fails in opt builds. In debug builds the test crashes Firefox:

WARNING: Bad accessible tree!: file /home/robod/src/mozilla-mihai-devtools-work/accessible/src/base/nsAccessible.cpp, line 2779
Assertion failure: ((Shape*)prop)->slot == globalScope.globalFreeSlot + i, at /home/robod/src/mozilla-mihai-devtools-work/js/src/jsparse.cpp:1008

The crasher happens before there's any output from the mochitest.

I should mention that even things like Math.random() throw, or if I define variables, then they are thought to be undefined at times. (Having played with the TC a lot, I've seen such type of errors.)

Any thoughts?

Comment 5

[David Dahl :ddahl]

This feels like a real edge case to me. What happens if you open the console, wit one or two seconds and reload the page? do things execute then?

Comment 6

[Mihai Sucan [:msucan]]

(In reply to comment #5)
> This feels like a real edge case to me. What happens if you open the console,
> wit one or two seconds and reload the page? do things execute then?

Things run fine if you open/close the web console before or after the page (re)loads. You must properly time the open/close, such that it runs during page script execution.

While it looks like an edge case ... I'd be curious if it doesn't affect web apps like gmail or gdocs. Those execute lots of code almost all the time. Also, users tend to have several tabs open (I do have 100+ tabs open in my browser - I know, I am waaay over the average, but still).

What may seem as an "innocent" exception in gmail, through the tons of warnings on twitter, or whatever... we may add one or more exceptions when the user opens the Web Console. I doubt the culprit lies in the Web Console code - might be a threading issue in jsparser.cpp or somewhere in the JS engine.

Someone with JS experience from the Gecko land should perhaps look into this.

Comment 7

[David Dahl :ddahl]

I guess what I am saying is let's not spend too many cycles on this until we get reports from the wild. Once we get those reports we can handle debugging this problem with more STRs.

Comment 8

[Patrick Walton (:pcwalton)]

Nominating for blocking status for Firefox 4. This is not only causing pages to break, but is actually crashing Firefox. This could have security implications.

Comment 9

[Mihai Sucan [:msucan]]

Removing blocking2.0 request as asked by David, and updating title.

I should mention that the crasher only occurs using the mochitest in debug builds.

Comment 10

[Patrick Walton (:pcwalton)]

Reproduced first try. Just went to http://robodesign.ro/, hold down cmd+shift+k, and I got this:

Assertion failure: ((Shape*)prop)->slot == globalScope.globalFreeSlot + i, at /Users/pwalton/Source/moz/mozilla-central/js/src/jsparse.cpp:1008

(long beachball)

Segmentation fault

This is a crasher for sure. Nominating for blocking2.0 once again.

Comment 11

[Patrick Walton (:pcwalton)]

Assertion failure: ((Shape*)prop)->slot == globalScope.globalFreeSlot + i, at /Users/pwalton/Source/moz/mozilla-central/js/src/jsparse.cpp:1008

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000101938f90 in JS_Assert (s=0x101d9b9d8 "((Shape*)prop)->slot == globalScope.globalFreeSlot + i", file=0x101d9a490 "/Users/pwalton/Source/moz/mozilla-central/js/src/jsparse.cpp", ln=1008) at /Users/pwalton/Source/moz/mozilla-central/js/src/jsutil.cpp:80
80	    *((int *) NULL) = 0;  /* To continue from here in GDB: "return" then "continue". */
(gdb) bt
#0  0x0000000101938f90 in JS_Assert (s=0x101d9b9d8 "((Shape*)prop)->slot == globalScope.globalFreeSlot + i", file=0x101d9a490 "/Users/pwalton/Source/moz/mozilla-central/js/src/jsparse.cpp", ln=1008) at /Users/pwalton/Source/moz/mozilla-central/js/src/jsutil.cpp:80
#1  0x00000001018dd13a in js::Compiler::compileScript (cx=0x120366900, scopeChain=0x11e538150, callerFrame=0x0, principals=0x1229efee8, tcflags=24576, chars=0x1213c3a08, length=34499, file=0x0, filename=0x119cf4c58 "http://www.robodesign.ro/js/index.js", lineno=1, source=0x0, staticLevel=0) at /Users/pwalton/Source/moz/mozilla-central/js/src/jsparse.cpp:1008
#2  0x00000001017cc450 in JS_EvaluateUCScriptForPrincipals (cx=0x120366900, obj=0x11e538150, principals=0x1229efee8, chars=0x1213c3a08, length=34499, filename=0x119cf4c58 "http://www.robodesign.ro/js/index.js", lineno=1, rval=0x0) at /Users/pwalton/Source/moz/mozilla-central/js/src/jsapi.cpp:4769
#3  0x00000001017cc6a2 in JS_EvaluateUCScriptForPrincipalsVersion (cx=0x120366900, obj=0x11e538150, principals=0x1229efee8, chars=0x1213c3a08, length=34499, filename=0x119cf4c58 "http://www.robodesign.ro/js/index.js", lineno=1, rval=0x0, version=JSVERSION_DEFAULT) at /Users/pwalton/Source/moz/mozilla-central/js/src/jsapi.cpp:4751
#4  0x000000010093099b in nsJSContext::EvaluateString (this=0x120366890, aScript=@0x120aa9408, aScopeObject=0x11e538150, aPrincipal=0x1229efee0, aURL=0x119cf4c58 "http://www.robodesign.ro/js/index.js", aLineNo=1, aVersion=0, aRetValue=0x0, aIsUndefined=0x7fff5fbfd780) at /Users/pwalton/Source/moz/mozilla-central/dom/base/nsJSEnvironment.cpp:1704
#5  0x00000001006a0833 in nsScriptLoader::EvaluateScript (this=0x119ccd040, aRequest=0x120aa93e0, aScript=@0x120aa9408) at /Users/pwalton/Source/moz/mozilla-central/content/base/src/nsScriptLoader.cpp:816
#6  0x00000001006a0c3d in nsScriptLoader::ProcessRequest (this=0x119ccd040, aRequest=0x120aa93e0) at /Users/pwalton/Source/moz/mozilla-central/content/base/src/nsScriptLoader.cpp:716
#7  0x00000001006a0db7 in nsScriptLoader::ProcessPendingRequests (this=0x119ccd040) at /Users/pwalton/Source/moz/mozilla-central/content/base/src/nsScriptLoader.cpp:859
#8  0x00000001006a472f in nsRunnableMethodImpl<void (nsScriptLoader::*)(), true>::Run (this=0x11d5aee40) at nsThreadUtils.h:347
#9  0x00000001015f65d0 in nsThread::ProcessNextEvent (this=0x10551db80, mayWait=0, result=0x7fff5fbfda94) at /Users/pwalton/Source/moz/mozilla-central/xpcom/threads/nsThread.cpp:547
#10 0x000000010157eec5 in NS_ProcessPendingEvents_P (thread=0x10551db80, timeout=20) at nsThreadUtils.cpp:200
#11 0x0000000101345c84 in nsBaseAppShell::NativeEventCallback (this=0x105585cf0) at /Users/pwalton/Source/moz/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:131
#12 0x00000001012fd9d2 in nsAppShell::ProcessGeckoEvents (aInfo=0x105585cf0) at /Users/pwalton/Source/moz/mozilla-central/widget/src/cocoa/nsAppShell.mm:394
#13 0x00007fff87a64e91 in __CFRunLoopDoSources0 ()
#14 0x00007fff87a63089 in __CFRunLoopRun ()
#15 0x00007fff87a6284f in CFRunLoopRunSpecific ()
#16 0x00007fff853a891a in RunCurrentEventLoopInMode ()
#17 0x00007fff853a867d in ReceiveNextEventCommon ()
#18 0x00007fff853a85d8 in BlockUntilNextEventMatchingListInMode ()
#19 0x00007fff8697c29e in _DPSNextEvent ()
#20 0x00007fff8697bbed in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#21 0x00007fff869418d3 in -[NSApplication run] ()
#22 0x00000001012fd2ea in nsAppShell::Run (this=0x105585cf0) at /Users/pwalton/Source/moz/mozilla-central/widget/src/cocoa/nsAppShell.mm:747
#23 0x000000010106a926 in nsAppStartup::Run (this=0x10559ea90) at /Users/pwalton/Source/moz/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:191
#24 0x0000000100032a1b in XRE_main (argc=3, argv=0x7fff5fbff808, aAppData=0x105515fb0) at /Users/pwalton/Source/moz/mozilla-central/toolkit/xre/nsAppRunner.cpp:3667
#25 0x000000010000127f in main (argc=3, argv=0x7fff5fbff808) at /Users/pwalton/Source/moz/mozilla-central/browser/app/nsBrowserApp.cpp:158

Comment 12

[Patrick Walton (:pcwalton)]

Looks like the crash is bug 595612.

Comment 13

[Mihai Sucan [:msucan]]

Re-checked this bug now that bug 595612 is fixed. I can no longer reproduce the failure.

The mochitest still fails because deactivateHUDForContext() runs and ultimately throws. This is going to be fixed in other upcoming patches (see bug 597103).