Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 727987 - Assertion failure: obj, at ../../jsval.h:774 or Crash on heap (JIT) or Crash [@ js::gc::ChunkBitmap::markIfUnmarked] with OOM
: Assertion failure: obj, at ../../jsval.h:774 or Crash on heap (JIT) or Crash ...
: crash, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Linux
: -- critical (vote)
: mozilla13
Assigned To: Bill McCloskey (:billm)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: langfuzz 695756
  Show dependency treegraph
Reported: 2012-02-16 13:47 PST by Christian Holler (:decoder)
Modified: 2012-07-12 08:54 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (687 bytes, patch)
2012-02-16 14:44 PST, Bill McCloskey (:billm)
jwalden+bmo: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2012-02-16 13:47:46 PST
The following test asserts/crashes on mozilla-central revision 4a9a6ffd1f21:

gcparam("maxBytes", gcparam("gcBytes") + 4*(1));
arr = [1e0, 5e1, 9e19, 0.1e20, 1.3e20, 1e20, 9e20, 9.99e20, 
    0.1e21, 1e21, 1e21+65537, 1e21+65536, 1e21-65536, 1]; 
for (var i = 0; i < 4000; i++) {
    arr.push(new Boolean(false));

When stepping through the assert, I first got this crash with options -m -n:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f3fcd9 in ?? ()
(gdb) bt
#0  0x00007ffff7f3fcd9 in ?? ()
#1  0x00007ffff7f3fc2e in ?? ()
#2  0x0000000000000001 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) x /4i $pc
=> 0x7ffff7f3fcd9:      mov    0x8(%rsi),%rsi
   0x7ffff7f3fcdd:      movabs $0x7ffff6000250,%r11
   0x7ffff7f3fce7:      cmp    %r11,%rsi
   0x7ffff7f3fcea:      je     0x7ffff7f3fcf5
(gdb) info register rsi
rsi            0x0      0

This looked like a simple null-deref. However, without any options, I get this crash:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004b9dcc in js::gc::ChunkBitmap::markIfUnmarked (this=0xfc0b8, cell=0x0, color=0) at /srv/repos/larch/js/src/jsgc.h:666
666             if (*word & mask)
(gdb) x / 4i $pc
Invalid number "4i".
(gdb) x /4i $pc
=> 0x4b9dcc <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+58>:    mov    (%rax),%rdx
   0x4b9dcf <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+61>:    mov    -0x10(%rbp),%rax
   0x4b9dd3 <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+65>:    and    %rdx,%rax
   0x4b9dd6 <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+68>:    test   %rax,%rax
(gdb) info register rax rdx
rax            0xfc0b8  1032376
rdx            0xfc0b8  1032376

which is certainly security-relevant. I can't judge if you can get the non-jitted crash in the browser somehow, so I'm marking this s-s.
Comment 1 Bill McCloskey (:billm) 2012-02-16 14:44:01 PST
Created attachment 598006 [details] [diff] [review]

It's an OOM.
Comment 2 Bill McCloskey (:billm) 2012-02-16 14:52:11 PST
Also, we'll always crash at exactly the same address that Christian saw (0xfc0b8). I'm not sure what the security implications of that are. It seems possible that there could be important stuff there, and we're going to set a bit on that word. But I think an attacker would have to be pretty clever to exploit this.
Comment 3 Christian Holler (:decoder) 2012-02-16 14:53:54 PST
Heh, I'm just afraid once I see "gc" with a crash and a non-null address ^_^
Comment 5 Bill McCloskey (:billm) 2012-02-24 08:11:50 PST
Comment 6 Daniel Veditz [:dveditz] 2012-03-17 08:50:24 PDT
This is a regression from bug 695756 so it affects the ESR, though it doesn't seem needed.
Comment 7 Christian Holler (:decoder) 2012-03-28 15:29:31 PDT
JSBugMon: This bug has been automatically verified fixed.

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