Closed Bug 980384 Opened 6 years ago Closed 6 years ago

Assertion failure: slot < numValueSlots(), at jit/BaselineFrame.h:150 or Bus Error

Categories

(Core :: JavaScript Engine: JIT, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox29 --- unaffected
firefox30 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: decoder, Assigned: wingo)

Details

(Keywords: assertion, crash, testcase, Whiteboard: [jsbugmon:update])

Attachments

(2 files)

The following testcase asserts on mozilla-central revision 8122ffa9e1aa (run with --fuzzing-safe):


function testcase() {
  try {
    testcase('(function (){var arguments;});');
  }
  catch (e) {
    return (testcase(0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
       0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
       0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
       0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
       0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
       0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
       0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9));
  }
}
testcase(testcase);
Crashes with a bus error:

Program received signal SIGBUS, Bus error.
0x00007ffff7ff1c4c in ?? ()
(gdb) x /i $pc
=> 0x7ffff7ff1c4c:      testl  $0x200,-0x8(%rbp)
(gdb) info reg rbp
rbp            0xfff9000000000000       0xfff9000000000000


Marked s-s based on that.
Keywords: crash
Whiteboard: [jsbugmon:update,bisect]
I would expect that we bailout from the try block when we exceed the recursion limit, but I do not see where the catch block is important here.

Jandem might be the right person to ask about this issue.
Flags: needinfo?(jdemooij)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20140225091817" and the hash "ecfb4d63943f".
The "bad" changeset has the timestamp "20140225092218" and the hash "cc698e2ff036".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ecfb4d63943f&tochange=cc698e2ff036
Needinfo from wingo based on comment 4, likely regressed by bug 962599.
Flags: needinfo?(wingo)
Assignee: nobody → wingo
Comment on attachment 8388401 [details] [diff] [review]
Fix frame marker for half-constructed stack frames

Unfortunately I was unable to produce a test case.  Your test case recurses until it reaches the stack limit, then hammers at the stack limit with a recursive function with many locals until GC happens during an early stack check.  There's no obvious way to make the test terminate, at least that I can see, and it's going to be n-squared on Mac due to its larger stack size and the cost of constructing the exception.
Attachment #8388401 - Flags: review?(jdemooij)
Flags: needinfo?(wingo)
Comment on attachment 8388401 [details] [diff] [review]
Fix frame marker for half-constructed stack frames

Review of attachment 8388401 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch.
Attachment #8388401 - Flags: review?(jdemooij) → review+
Flags: needinfo?(jdemooij)
This shouldn't have landed without security approval since it doesn't have a rating and isn't clear what branches it affects.
https://hg.mozilla.org/mozilla-central/rev/7450b87d6ff4
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
> There's no obvious way to make the test terminate, at least that I can see, 
> and it's going to be n-squared on Mac due to its larger stack size and the 
> cost of constructing the exception.

Perhaps you could fix bug 813646 and/or bug 735082?

I've stopped fuzzing these too-much-recursion corners because even fuzz testcases are slow and unreliable. Meanwhile, Decoder is finding plenty of bugs with this pattern (e.g. this bug, bug 978811, bug 970252, bug 957716).
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #10)
> This shouldn't have landed without security approval since it doesn't have a
> rating and isn't clear what branches it affects.
> https://hg.mozilla.org/mozilla-central/rev/7450b87d6ff4

As I understand the guidelines, this was simply a recent regression in m-c that never shipped, and so landing it directly was OK.
Group: core-security
You need to log in before you can comment on or make changes to this bug.