http://syntensity.com/static/ammo.html is a demo of Bullet compiled to JS. It works on Nightly on the 19th, but the Nightly of the 20th gives incorrect behavior: the bricks fall, then as they hit the ground, some of them vanish, then all of them vanish. The correct behavior is for none of them to vanish, then after they settle down eventually they are dropped again and so forth. My first guess is that a significant patch landed for the 20th that compiles large scripts (which this is) in chunks, bug 706914 (this is why I tested the demo). Is there perhaps a pref to turn that off to check?
Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/1f6244d044aa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118160212 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/d0c192e5bd41 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118164112 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1f6244d044aa&tochange=d0c192e5bd41 Triggered by d0c192e5bd41 Brian Hackett — Compile large scripts in chunks, bug 706914. r=dvander
Is there a shell version of the demo that exhibits incorrect behavior? The browser demo seems non deterministic (blocks fall different ways each time) which makes identifying the problem hard to track down.
You can make the browser demo deterministic like this: git clone email@example.com:kripken/ammo.js.git cd ammo.js Edit examples/webgl_demo/ammo.html, replacing Math.random() with say 0 python -m SimpleHTTPServer 8888 firefox localhost:8888/examples/webgl_demo/ammo.html
I also figured out how to run a shell version of this. Clone the git repo in the previous comment, then inside that clone do js -m -n -e "load('builds/ammo.js')" tests/stress.js The numbers start out ok, then almost all become NaNs (which doesn't happen in previous builds, or without -n).
Created attachment 590607 [details] testcase It was difficult, but succeeded in creating a reduced testcase. Testcase points in the direction of Float64Array and a function argument. Testcase should give 0 (without -n or in the interpreter), but currently gives NaN in "-m -n"
Created attachment 590712 [details] [diff] [review] patch Great testcase, thanks! Normally when compiling, if we hit a control flow join point where a variable is a known integer from the previous opcode but is a known double on other incoming paths (as at the end of the do-while loop), we need to coerce the variable into a double to make sure it has a consistent representation on all paths. This was being skipped if that join point was the start of a new chunk. This patch fixes the testcase, and no NaNs are being generated by the stress test.
Works great, marking verified.