Closed Bug 719918 Opened 8 years ago Closed 8 years ago

Bullet JS demo broke on Nightly Jan 20


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
firefox12 + fixed


(Reporter: azakai, Assigned: bhackett1024)




(Keywords: regression)


(2 files)

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?
Keywords: regression
Version: unspecified → Trunk
Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118160212
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118164112

Triggered by
d0c192e5bd41	Brian Hackett — Compile large scripts in chunks, bug 706914. r=dvander
Blocks: 706914
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
  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).
Attached file 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"
Attached patch patchSplinter Review
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.
Assignee: general → bhackett1024
Attachment #590712 - Flags: review?(dvander)
Attachment #590712 - Flags: review?(dvander) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Works great, marking verified.
You need to log in before you can comment on or make changes to this bug.