Closed Bug 848803 Opened 8 years ago Closed 8 years ago

JS engine changes in Nightly have broken JSIL demos

Categories

(Core :: JavaScript Engine, defect)

x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla22
Tracking Status
firefox22 + fixed

People

(Reporter: kael, Assigned: h4writer)

References

()

Details

(Keywords: regression)

Attachments

(3 files)

Recent JS engine changes in Nightly have broken JSIL demos such that they frequently fail while parsing type names (JSIL.ParseTypeName) during the process of loading content (typically XNA SpriteFont assets). In particular, I can reproduce this almost 100% of the time by running Escape Goat (see URL) in Nightly. It still works fine in Chrome and Aurora and I've verified that this isn't caused by any recent code changes on my end.

I can't debug this because enabling Firebug or the built-in Debugger causes the browser to perform horribly and hang indefinitely roughly when the error would have occurred.

Occasionally it does work in Nightly which makes me suspect the problem is intermittent somehow.

One possibility I haven't ruled out is that the startup code could be overflowing the stack; type initialization is by necessity recursive and I know SpiderMonkey responds incredibly poorly to stack overflows.

The failure looks like this in the log (click Show Log):

Unhandled exception at line 0:
uncaught exception: Microsoft.Xna.Framework.Content.ContentLoadException: Failed to load asset 'DebugFont' because an asset loader threw an exception.
-- Inner exception follows --
Error: The type 'Microsoft.Xna.Framework.Content.SpriteFontReader, Microsoft.Xna.Framework.Graphics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=842cf8be1de50553' could not be found while loading asset 'DebugFont'.

Marking 848665 as a dependency since that debugger problem prevents me from looking into this further myself (apologies if that's wrong :D)

URL tested and working in:

Aurora 21.0a2 (2013-03-06)
Chrome Version 27.0.1432.0 canary
IE 10.0.9200.16521
Is there a regression range by chance?
(In reply to Kevin Gadd (:kael) from comment #0)
> One possibility I haven't ruled out is that the startup code could be
> overflowing the stack; type initialization is by necessity recursive and I
> know SpiderMonkey responds incredibly poorly to stack overflows.

It is OOM we respond poorly too, stack overflow reliably generates an exception and is somewhat well-tested.
No. Is there a bisect tool out there I could run to generate you one? Alternately, a folder full of dated nightly builds would be enough.
I already tried digging through the nightly builds folder but I couldn't make sense of all the branch names and the layout of the folders. It'd be great to have a 'build names for dummies' page somewhere easy-to-find that explains what branch name is trunk and how to find the build for a given date.

I'm installing mozregression right now, thanks.
(In reply to Luke Wagner [:luke] from comment #3)
> (In reply to Kevin Gadd (:kael) from comment #0)
> > One possibility I haven't ruled out is that the startup code could be
> > overflowing the stack; type initialization is by necessity recursive and I
> > know SpiderMonkey responds incredibly poorly to stack overflows.
> 
> It is OOM we respond poorly too, stack overflow reliably generates an
> exception and is somewhat well-tested.

That's really good to hear; the last time I had to debug a JS stack overflow in Firefox it required setting breakpoints in the JS engine from a debugger and extracting the stack by looking at locals. :)


(In reply to Boris Zbarsky (:bz) from comment #5)
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and
> http://harthur.github.com/mozregression/

OK, mozregression rules. Here's a preliminary regression range (I tested loading the game 3 times in each build)

Last good nightly: 2013-02-22
First bad nightly: 2013-02-23

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=885cde564ff3&tochange=08a034e1d43a

I'll try and bisect with local builds but no promises; I always seem to have trouble building firefox locally.
Trunk is "mozilla-central", for what it's worth.

There's a bunch of jseng changes in that regression range, unfortunately.  :(
(In reply to Boris Zbarsky (:bz) from comment #8)
> Trunk is "mozilla-central", for what it's worth.
> 
> There's a bunch of jseng changes in that regression range, unfortunately.  :(

Yeah, when I looked at the pushlog my brain made a little slide whistle noise. I've got mozregression doing the fetch/build for a bisect, so maybe that'll be fast and I'll be able to nail down a commit or group of commits.

If I can ease debugging this by adding instrumentation to the JS, let me know and I can push a new build to that public server and give you a URL for it.
OK, I can't figure out how to get mozregression to bisect commits. I already had to fiddle with my mercurial.ini and deviate from the directions on the mozregression site so it could find my compiler, but I don't know what to do about this:

Adding configure options from c:/Users/Kevin\.moz-commitbuilder-cache\mozconf\config-default:
  --disable-optimize
  --enable-debug
  --enable-tests
  --with-windows-version=600
  --enable-application=browser
configure: error: Invalid value for --with-windows-version (600)
make[2]: *** [configure] Error 1
make[1]: *** [/c/Users/Kevin/.moz-commitbuilder-cache/mozbuild-trunk/obj-ff-dbg/Makefile] Error 2
make: *** [build] Error 2
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/885cde564ff3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130221 Firefox/22.0 ID:20130221115546
Bad:
http://hg.mozilla.org/mozilla-central/rev/67f2a2816651
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130221 Firefox/22.0 ID:20130222031138
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=885cde564ff3&tochange=67f2a2816651

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/45a1e69221ef
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130221 Firefox/22.0 ID:20130221064259
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9fb2083111af
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130221 Firefox/22.0 ID:20130221065759
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=45a1e69221ef&tochange=9fb2083111af

Suspicion bug: Bug 843038, Bug 843518
In local build:
Last Good: 9d5e10ca36a4
First Bad: 9fb2083111af
Triggered by :
9fb2083111af	Hannes Verschore — Bug 843038: IonMonkey: Correct the definition of when an instruction is part of the loop, r=jandem
Blocks: 843038
Assignee: general → hv1989
The bug shows itself in "JSIL.ParseTypeNameImpl" (JSIL.Core.js:5764). And only when ion-parallel-compile=on. I.e. when users have 2+ cores. Else the function is to big to get compiled by ionmonkey.
Assignee: hv1989 → general
Can you provide a standalone version of this? So I can run it locally.
It's been a pain in the ass to debug this problem remotely.
Assignee: general → hv1989
Here's a headless version of the code that breaks in the browser. Sadly, no matter what I do I can't get this to break in the JS shell, but I figure it might still be useful...
till and dvander on #jsapi helped me figure out a way to intermittently reproduce this in the js shell using the headless test case:

js --ion-parallel-compile=on --no-jm --ion-eager runTest.js

Will sometimes cause the failure to occur a few times during the startup phase of the headless test. Interestingly, the actual loop where it loads the asset never seems to fail. Some sort of race.

You're looking for the text 'could not be found while loading asset'. A failure looks like this:


C:\Users\Kevin\Desktop\ParseTypeNameBug>js --ion-parallel-compile=on --no-jm --ion-eager runTest.js
Loading DebugFont.xnb 1024 time(s)
Could not resolve open generic parameter 'System.Threading.Tasks.Shared`1.T' when building field list for type 'System.T
hreading.Tasks.Shared`1'

Could not resolve open generic parameter 'System.Threading.Tasks.Task`1.TResult' when building field list for type 'Syst
em.Threading.Tasks.Task`1'

The external method 'void .ctor()' of type 'System.IO.Stream' has not been implemented; calling inherited method.

The external method 'void .ctor()' of type 'System.MarshalByRefObject' has not been implemented; calling inherited metho
d.

The external method 'System.Int32 ReadByte()' of type 'System.IO.MemoryStream' has not been implemented; calling inherit
ed method.

The type 'Microsoft.Xna.Framework.Content.Texture2DReader, Microsoft.Xna.Framework.Graphics, Version=4.0.0.0, Culture=ne
utral, PublicKeyToken=842cf8be1de50553' could not be found while loading asset 'DebugFont'.
ReadTypeManifest@TestLibraries/JSIL.XNA.Content.js:564
PreInitMethod_Invoke@TestLibraries/JSIL.Core.js:476
PreInitMethod_Invoke@TestLibraries/JSIL.Core.js:476
ReadHeader@TestLibraries/JSIL.XNA.Content.js:697
RawXNBAsset_ReadAsset@TestLibraries/JSIL.XNA.Core.js:161
runMain@runTest.js:145
shellStartup@TestLibraries/JSIL.Shell.js:105
@runTest.js:157

The type 'Microsoft.Xna.Framework.Content.SpriteFontReader, Microsoft.Xna.Framework.Graphics, Version=4.0.0.0, Culture=n
eutral, PublicKeyToken=842cf8be1de50553' could not be found while loading asset 'DebugFont'.
ReadTypeManifest@TestLibraries/JSIL.XNA.Content.js:564
PreInitMethod_Invoke@TestLibraries/JSIL.Core.js:476
PreInitMethod_Invoke@TestLibraries/JSIL.Core.js:476
ReadHeader@TestLibraries/JSIL.XNA.Content.js:697
RawXNBAsset_ReadAsset@TestLibraries/JSIL.XNA.Core.js:161
runMain@runTest.js:145
shellStartup@TestLibraries/JSIL.Shell.js:105
@runTest.js:157

The type 'Microsoft.Xna.Framework.Content.SpriteFontReader, Microsoft.Xna.Framework.Graphics, Version=4.0.0.0, Culture=n
eutral, PublicKeyToken=842cf8be1de50553' could not be found while loading asset 'DebugFont'.
ReadTypeManifest@TestLibraries/JSIL.XNA.Content.js:564
PreInitMethod_Invoke@TestLibraries/JSIL.Core.js:476
PreInitMethod_Invoke@TestLibraries/JSIL.Core.js:476
ReadHeader@TestLibraries/JSIL.XNA.Content.js:697
RawXNBAsset_ReadAsset@TestLibraries/JSIL.XNA.Core.js:161
runMain@runTest.js:145
shellStartup@TestLibraries/JSIL.Shell.js:105
@runTest.js:157

The external method 'System.Single ReadSingle()' of type 'Microsoft.Xna.Framework.Content.ContentReader' has not been im
plemented; calling inherited method.

Could not resolve open generic parameter 'System.Nullable`1.T' when building field list for type 'System.Nullable`1'

....................................................................^C
More fiddling: js --no-jm --ion-eager runTest.js makes it completely busted. Fails every loop iteration. Not sure why parallel compile makes it better...
Attached file Reduced js testcase
Thanks gkw for helping on this one. This testcase shouldn't assert under ionmonkey. There is something fishy going on. Looks like u.assembly isn't set to the right value, but looking at LIRs, the opcodes are correct.
Attachment #723954 - Flags: review?(jdemooij) → review+
https://hg.mozilla.org/mozilla-central/rev/a9e5d4379740
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Confirmed fixed in 22.0a1 (2013-03-14)
You need to log in before you can comment on or make changes to this bug.