Last Comment Bug 743088 - Consistent failure of jit-test bug673812.js on 64-bit with -a -m -n
: Consistent failure of jit-test bug673812.js on 64-bit with -a -m -n
: regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla14
Assigned To: Brian Hackett (:bhackett)
: Jason Orendorff [:jorendorff]
: 743706 (view as bug list)
Depends on:
Blocks: 741544
  Show dependency treegraph
Reported: 2012-04-05 17:14 PDT by David Mandelin [:dmandelin]
Modified: 2012-04-10 08:45 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

stack trace (7.35 KB, text/plain)
2012-04-05 17:38 PDT, Bill McCloskey (:billm)
no flags Details
patch (1.40 KB, patch)
2012-04-09 16:55 PDT, Brian Hackett (:bhackett)
luke: review+
Details | Diff | Splinter Review

Description User image David Mandelin [:dmandelin] 2012-04-05 17:14:23 PDT
This is really bug 741544, but filing a new bug because the failspam (though useful for noticing the problem) makes it hard to read comments. 

I can reproduce on 64-bit OSX with

  python ../jit-test/ --valgrind --jitflags
=amn shell/js 673812 -so


  shell/js -m -n -a -e "const platform='darwin'; const libdir='/Users/dmandelin/sources/mozilla-central/js/src/jit-test/lib/';" -f /Users/dmandelin/sources/mozilla-central/js/src/jit-test/lib/prolog.js -f /Users/dmandelin/sources/mozilla-central/js/src/jit-test/tests/jaeger/recompile/bug673812.js

Annoyingly, it doesn't repro for me in gdb, but it does repro in valgrind. I'll attach a valgrind report, but it's in JITScript::chunkIndex, so guessing chunked compilation.
Comment 1 User image Bill McCloskey (:billm) 2012-04-05 17:38:48 PDT
Created attachment 612760 [details]
stack trace

I tried reproducing this myself. It happens every 10 runs or so. I was able to bisect it to this:

The first bad revision is:
changeset:   90829:3a185f034768
user:        Luke Wagner <>
date:        Mon Apr 02 08:57:27 2012 -0700
summary:     Bug 740654 - Hoist recursion checks out of Interpret into callers so that Interpret does not throw when trying to rejoin from mjit (r=bhackett)

I also have a stack trace. It has over 1000 frames on it, so I only included the top. Given the patch's summary, it seems likely to be related to a stack overflow, I guess.
Comment 2 User image Luke Wagner [:luke] 2012-04-06 10:32:24 PDT
I looked at a core dump (I can also repro 1 in 10 on Linux).  I'm thinking that bug 740654 is tickling a different bug by causing an over-recursed error to appear in a new place.  What seems to be happening is that we are in ic::Call, we call stubs::UncachedCallHelper, that throws 'over recursed', and then later in CallCompiler::update, in the "if (!ucr.codeAddr && ucr.unjittable)" branch, we call disable() which passes f.chunk() == NULL to Repatcher which crashes becuase it assumes non-NULL.

Brian, I don't understand chunked compilation, could you weigh in?  The f.chunk() == NULL makes me think this this might be a simple error handling issue.
Comment 3 User image Luke Wagner [:luke] 2012-04-09 09:41:13 PDT
*** Bug 743706 has been marked as a duplicate of this bug. ***
Comment 4 User image Brian Hackett (:bhackett) 2012-04-09 16:55:23 PDT
Created attachment 613432 [details] [diff] [review]

As discussed with luke on IRC, the issue is that the IC is trying to disable itself while the callee's frame is still on the stack (the callee throws but doesn't unwind).
Comment 5 User image Brian Hackett (:bhackett) 2012-04-09 17:34:52 PDT

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