Last Comment Bug 643805 - TI: Incorrect results with compiled FreeType
: TI: Incorrect results with compiled FreeType
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86 Linux
: -- normal (vote)
: ---
Assigned To: general
:
:
Mentors:
Depends on: 648769
Blocks: infer-regress
  Show dependency treegraph
 
Reported: 2011-03-22 10:29 PDT by Alon Zakai (:azakai)
Modified: 2011-04-19 06:52 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
freetype - two versions (1.92 MB, application/octet-stream)
2011-03-22 10:29 PDT, Alon Zakai (:azakai)
no flags Details
freetype - gcc version (904.36 KB, application/octet-stream)
2011-03-22 15:31 PDT, Alon Zakai (:azakai)
no flags Details
Reduced (667 bytes, application/x-javascript)
2011-03-26 06:00 PDT, Jan de Mooij [:jandem]
no flags Details
Reduced (654 bytes, application/x-javascript)
2011-03-26 07:10 PDT, Jan de Mooij [:jandem]
no flags Details
Reduced (630 bytes, application/x-javascript)
2011-04-16 02:17 PDT, Jan de Mooij [:jandem]
no flags Details

Description Alon Zakai (:azakai) 2011-03-22 10:29:43 PDT
Created attachment 520955 [details]
freetype - two versions

The attachment is FreeType compiled to JavaScript (two versions - one with optimizations, one without). Running it in jaegermonkey with -m and parameters |font.ttf test 80 75 2| gives incorrect results (an error in one version, an infinite loop in the other). The output without -m (and with the same parameters) is valid (it shows some ascii art).

This is similar and perhaps related to bug 643635.
Comment 1 Alon Zakai (:azakai) 2011-03-22 10:33:41 PDT
Um, this shouldn't be a security sensitive bug - I guess I clicked the wrong button when filing it.

I don't see a way to undo that...?
Comment 2 Alon Zakai (:azakai) 2011-03-22 15:31:18 PDT
Created attachment 521047 [details]
freetype - gcc version

An additional build of FreeType, this time with llvm-gcc (other ones were with clang).

This build crashes with -j (with the same arguments as before), unlike the other ones. Otherwise it is similar, no JITs works, -m gives incorrect output (0's).
Comment 3 Jan de Mooij [:jandem] 2011-03-25 03:08:52 PDT
The patch in bug 643829 does not fix this. Reducing...
Comment 4 Jan de Mooij [:jandem] 2011-03-26 06:00:13 PDT
Created attachment 522098 [details]
Reduced

My laptop spent most of yesterday attacking this 214,755 lines monster. Let's hope there's only one bug here ;)

$ ./js -m -a test.js
test.js:22: Error: Assertion failed: got (void 0), expected 0

Looks a lot like bug 642569 (>50 locals)
Comment 5 Jan de Mooij [:jandem] 2011-03-26 07:10:55 PDT
Created attachment 522105 [details]
Reduced

This one may be easier to debug.
Comment 6 Jan de Mooij [:jandem] 2011-04-04 06:43:35 PDT
Reduced testcase passes now but Freetype still fails with |-m -n| (incorrect result) so I'll probably have to reduce this again..
Comment 7 Alon Zakai (:azakai) 2011-04-09 10:20:18 PDT
Looks like this happens on tracemonkey too, so it might not be a TI bug. Filed bug 648769.
Comment 8 Jan de Mooij [:jandem] 2011-04-15 10:01:44 PDT
Output is still incorrect with -n, I'll reduce this now.
Comment 9 Alon Zakai (:azakai) 2011-04-15 10:13:49 PDT
Jan: This is still a problem on tracemonkey, so it is likely not a TI issue, as mentioned in comment #7. If you can reduce for tracemonkey for bug 648769, though, that would be extremely useful - we are having a hard time finding the cause by bisection!
Comment 10 Jan de Mooij [:jandem] 2011-04-15 10:50:12 PDT
(In reply to comment #9)
> Jan: This is still a problem on tracemonkey, so it is likely not a TI issue, as
> mentioned in comment #7. 

I'm using freetype_gcc_1_1.js. It works with -m, but with -m -n it prints incorrect values.

> If you can reduce for tracemonkey for bug 648769,
> though, that would be extremely useful - we are having a hard time finding the
> cause by bisection!

Hm can't reproduce, will post details in the other bug.
Comment 11 Jan de Mooij [:jandem] 2011-04-16 02:17:37 PDT
Created attachment 526473 [details]
Reduced

This fails with |-m -n| and |-m -n -a|:

test.js:20: Error: Assertion failed: got false, expected true

It looks like it's evicting the result of $rec = $rec + 1 because it decides $rec is dead.
Comment 12 Brian Hackett (:bhackett) 2011-04-19 06:52:42 PDT
Bingo.  When running the liveness analysis on loop bodies, we initially assume that if the variable is dead after the loop it will be dead at the backedge too, and need to go and insert new lifetime segments if it is found to be live at the loop head.  This was broken though and did not insert new segments if the variable was written in the middle of the loop and those writes did not dominate the back edge.

http://hg.mozilla.org/projects/jaegermonkey/rev/d78eef12a329

Note You need to log in before you can comment on or make changes to this bug.