770089 - "Assertion failure: lifetime && lifetime->head == uint32_t(head - outerScript->code) && lifetime->entry == uint32_t(entryTarget - outerScript->code),"

Status: RESOLVED DUPLICATE of bug 781859

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

mjitChunkLimit(42);
Function("\
    switch (/x/) {\
        case 8:\
        break;\
        t(function(){})\
    }\
    while (false)(function(){})\
")()

asserts js debug shell on m-c changeset 3be950fe9e1e with -m, -n and -a at Assertion failure: lifetime && lifetime->head == uint32_t(head - outerScript->code) && lifetime->entry == uint32_t(entryTarget - outerScript->code),

s-s because this concerns mjitChunkLimit and also because bug 741110 is marked s-s.

The regressing changeset of this bug seems to be different from that of bug 741110, so filing a separate bug.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   87695:f4e955f78de9
user:        Jeff Walden
date:        Fri Feb 03 18:53:29 2012 -0800
summary:     Bug 720316 - Use uint32_t indexes for JOF_ATOM opcodes.  r=jorendorff

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Jeff, want to take a stab at rating this one?
https://wiki.mozilla.org/Security_Severity_Ratings

Comment 2

[Jeff Walden [:Waldo]]

I'm guessing my changes, which changed bytecode lengths, caused the chunk-limit bit to hit at just the right place to trigger pre-existing badness.  I bet if you try a build before my changes and pass in mjitChunkLimit values less than 42 (I inflated bytecode lengths, so it *should* be less) you'll be able to reproduce the bug.  CCing bhackett, this analysis code is more his area than mine...

Oh, as for rating this, I suspect the only way to do that precisely is to just fix the bug.  I'd only be willing to give a conservative sec-critical rating there, without knowing what exactly went wrong.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

As per Jeff's advice, changing the number in mjitChunkLimit down from 42 causes the following testcase:

mjitChunkLimit(41);
Function("\
    switch (/x/) {\
        case 8:\
        break;\
        t(function(){})\
    }\
    while (false)(function(){})\
")()

to assert before Jeff's changeset, so the initial regressing changeset fingered by autoBisect is wrong. Re-running autoBisect now...

Comment 4

[Jesse Ruderman]

By varying mjitChunkLimit in a loop, I was able to reduce the testcase and get an earlier regressing changeset:

for (var i = 0; i < 60; ++i) {
  print(i);
  mjitChunkLimit(i);
  Function("\
      switch (0) {\
          case 1:\
          break;\
      }\
      while (false) { }\
  ")();
}

The first bad revision is:
changeset:   d0c192e5bd41
user:        Brian Hackett
date:        Wed Jan 18 16:40:18 2012 -0800
summary:     Compile large scripts in chunks, bug 706914. r=dvander

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Brian, can you pls look at taking this? Bisection seems to point to bug 706914, and Waldo is going to be gone for almost the entire Firefox 17 window.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Testcases in comment 0, comment 3 and comment 4 still assert with http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-08-09-mozilla-central-debug/jsshell-mac64.zip

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

I believe Waldo is back, so moving this back to him to see if there's a chance of getting something ready here for 16, we've still got a few weeks to land something to branches.

Comment 8

[Jesse Ruderman]

Waldo is back from his bike trip, but he just left again for a week near Donner Lake.

Comment 9

[Daniel Veditz [:dveditz]]

With Jeff out it's unrealistic to get this fix into Firefox 16, shipping in a couple weeks.

Comment 10

[Jan de Mooij [:jandem]]

Patches in bug 781859 fix this.