The default bug view has changed. See this FAQ.

TI+JM: Kraken crypto-aes regression

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jandem, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

1.42 KB, application/x-javascript
Details
(Reporter)

Description

6 years ago
Created attachment 527916 [details]
Reduced

$ ./js -n -m test.js
test.js:19: Error: Assertion failed: got -658505728, expected 1667457891
(Reporter)

Comment 1

6 years ago
Created attachment 527918 [details]
Reduced further
Attachment #527916 - Attachment is obsolete: true
(Reporter)

Comment 2

6 years ago
Created attachment 527920 [details]
Reduced

Oops, interpreter-based reducer did not handle nested operators.
Attachment #527918 - Attachment is obsolete: true
Before branching to an opcode we ensure that things known to be doubles at the target are in fact doubles.  They stayed as doubles in the fallthrough, however, and when we then branched to a point they were known to be integers we didn't fix them again and were left interpreting a double value as an integer.

This fixes things to check both double and integer types before branching, but I'm not sure it's the right fix (would like to get kraken working again, while I think some more).  There are a couple other places we fix int-to-double but not double-to-int and it might be better to just not tolerate the compiler treating things as doubles which were inferred as ints, and get a more tightly focused fix for this situation.

http://hg.mozilla.org/projects/jaegermonkey/rev/e044a9a69132
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
More targeted fix.  For branches with fallthroughs where we need to fix any double entries before branching, restore those fixed doubles before the next opcode.  We should maintain an invariant that any entries which were inferred as integers are not maintained as doubles by the compiler.  (Would be nice to maintain a stronger invariant that types in the compiler are always in sync with inferred types, but this may lose precision within inlined frames).

http://hg.mozilla.org/projects/jaegermonkey/rev/f394ef228e61
Fix to the last fix's fix for the first fix (bug that will not die).  When restoring doubles back to integers, we stored raw frame entries in vectors rather than getting them from the FrameState itself, and ended up accessing entries that weren't being tracked by the FrameState.

http://hg.mozilla.org/projects/jaegermonkey/rev/591e2ce89668
You need to log in before you can comment on or make changes to this bug.