Closed Bug 1093303 Opened 8 years ago Closed 7 years ago

StrategyGame does not play correctly

Categories

(Core :: JavaScript Engine: JIT, defect)

35 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox33 --- unaffected
firefox34 --- unaffected
firefox35 --- affected
firefox36 --- unaffected

People

(Reporter: sunfish, Unassigned)

References

Details

The demo at http://mzl.la/ue4 does not play correctly on Aurora (35). When I start the game, (I'm playing on Easy, but I don't know if that matters), units start walking out, but get stuck right at the first turn. The game continues to run and animations still run, but the units all just pile up in one spot.
Playing the game on Firefox Nightly (36) and released firefox (33) works fine. Of the versions I've tested so far, only Aurora has this bug.
Group: mozilla-employee-confidential
This is very peculiar. I can reproduce like you said. Stable and Nightly work ok, Aurora channel has the issue, Given that the issue clearly hits only game logic (the enemies are stuck in their paths), the first clue suggests a bug with a random number generator, timing, or similar and a fluke, but it does not seem to be so: the issue reproducibly does hit Aurora (5/5 tries) and never Nightly (3/3 tries) suggests that randomness/pathfinding/game logic bug is not at play here.
I've bisected this through mozilla-central, and I'm seeing the following:

Last good revision: 5bd6e09f074e (2014-09-22)
First bad revision: afc933adf723 (2014-09-23)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5bd6e09f074e&tochange=afc933adf723


Last bad revision: 88adcf8fef83 (2014-10-23)
First fixed revision: d6abb9bf43be (2014-10-24)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=88adcf8fef83&tochange=d6abb9bf43be


Very interestingly, the date the bug was introduced is identical to the date when this WebGL regression occurred: https://bugzilla.mozilla.org/show_bug.cgi?id=1087995 , which is also related to Unreal Engine 4.

My current _very wild hunch_ here is that the game is using grayscale texture images to represent passable terrain, and due to e.g. convenience, they are routing the data through WebGL textures, and we have a bug reading those textures back and presenting the pixel data for the engine to use in the pathfinding for passable terrain. This is a very random thought, not sure at all until I talk more with Epic guys.
Why is this security sensitive?
I think this is security sensitive by accident. That can be removed. However for some reason I cannot uncheck the sec sensitive checkbox in this bug.

Bisecting incoming shows that this bug is caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1085298 . The problem was introduced by this commit

https://hg.mozilla.org/mozilla-central/rev/6465e8acae5e
changeset:   206624:6465e8acae5e
user:        Hannes Verschore <hv1989@gmail.com>
date:        Tue Sep 23 09:42:05 2014 +0200
summary:     Bug 1064537: IonMonkey: Try folding ternary constructs, r=nbp

and subsequently fixed by this commit

https://hg.mozilla.org/mozilla-central/rev/c12ed538e44a
changeset:   211944:c12ed538e44a
user:        Hannes Verschore <hv1989@gmail.com>
date:        Thu Oct 23 15:34:13 2014 +0200
summary:     Bug 1085298 - IonMonkey: Fix for when folding ternary constructs and a branch dominates both MPhi predecessors, r=nbp

Uplifting the fix to Aurora should fix this. I don't understand why that was not done by default..
Not security sensitive, but I will keep the Confidential flag.
I'll uplift the patch as soon as I get permission.
Group: core-security
Component: General → JavaScript Engine: JIT
OS: Linux → All
Hardware: x86_64 → All
Same happened with bug 1085298 (another fold ternary bug). Landed on FF36, but not uplifted to FF35. I'll keep track of both.
(In reply to Hannes Verschore [:h4writer] from comment #7)
> Same happened with bug 1085298 (another fold ternary bug). Landed on FF36,
> but not uplifted to FF35. I'll keep track of both.

* bug 1090037
Yeah, the confidential flag is important, the url in comment 0 is subject to NDA and not public.
Hey guys, you can make this public.  The url is in a blog post that has already gone live.  It's just a minor blog post though and the main event will be the 10th anniversary.
Group: mozilla-employee-confidential
Oh, this was fixed according to Hannes's work, so closing.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.