Crash [@ JSScope::destroy] or "Assertion failure: slot < nslots," with sharps

RESOLVED WORKSFORME

Status

()

defect
--
critical
RESOLVED WORKSFORME
9 years ago
6 years ago

People

(Reporter: gkw, Unassigned)

Tracking

(Blocks 1 bug, 4 keywords)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(blocking2.0 betaN+, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(Whiteboard: [sg:critical][ccbr], crash signature)

Attachments

(1 attachment)

Reporter

Description

9 years ago
(#1=*)()

asserts js debug shell on TM changeset 0bc3ab72c26b without -j at Assertion failure: slot < nslots, at ../jsobj.cpp:6014
Reporter

Comment 1

9 years ago
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   49150:4d411039d112
user:        Blake Kaplan
date:        Thu Jul 15 23:49:13 2010 -0700
summary:     Bug 577750 - Make computing global this a little simpler. r=jorendorff
Blocks: 577750
bug 581263 will fix this. The problem is that we try to compute this before we realize that we can't actually call * as a function. * is an object that has no parent, so when we try to treat it like a global object, we crash.
Depends on: 581263
Reporter

Comment 3

9 years ago
I have a scary-looking testcase that crashes at a scary place for an opt shell and asserts similarly.
Group: core-security
blocking2.0: --- → ?
Keywords: crash
OS: Linux → All
Hardware: x86 → All
Whiteboard: [ccbr]
Reporter

Comment 4

9 years ago
Posted file testcase
(Pass in as a CLI argument to reproduce)

js-opt-32-tm-darwin(74648) malloc: *** error for object 0x11027e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xffff002f
0x000defc6 in JSScope::destroy ()
(gdb) bt
#0  0x000defc6 in JSScope::destroy ()
#1  0x00057cd0 in js_GC ()
#2  0x000246d2 in js_DestroyContext ()
#3  0x0000fad9 in JS_DestroyContext ()
#4  0x00003b03 in DestroyContext ()
#5  0x00009890 in main ()
(gdb) x/i $eip
0xdefc6 <_ZN7JSScope7destroyEP9JSContext+54>:   mov    %eax,0x28(%ebx)
(gdb) x/b $eax
0x3e7ff <js_EmitTree+4559>:     0xff
Reporter

Comment 5

9 years ago
TM changeset 27a70c60b48d:

$ ./js-dbg-32-tm-darwin nslotsOptCrash.js 
Assertion failure: slot < nslots, at ../jsobj.cpp:6013
Bus error
Summary: "Assertion failure: slot < nslots," with sharps → Crash [@ JSScope::destroy] or "Assertion failure: slot < nslots," with sharps
Whiteboard: [ccbr] → [sg:critical] fixed by 581263 [ccbr]

Updated

9 years ago
Whiteboard: [sg:critical] fixed by 581263 [ccbr] → [sg:critical][ccbr][fixed-in-tracemonkey by 581263]

Updated

9 years ago
blocking2.0: ? → betaN+
JSScope is all gone, what's the stack now?

/be

Comment 7

9 years ago
It no longer crashes, and was apparently fixed by a merge from JM.

$ ./autoBisect.py -p -s default -e 4d411039d112 -a 32 n.js

The first good revision is:
changeset:   52547:645e9f78e67a
parent:      52546:82c410fffaa8
parent:      49281:01a44b79f36c
user:        David Mandelin <dmandelin@mozilla.com>
date:        Wed Aug 11 11:30:10 2010 -0700
summary:     [JAEGER] Merge from tracemonkey.

I'm generally suspicious when hg bisect pinpoints a merge changeset, but I think it's actually correct this time.  The merge rev is "good", meaning it doesn't crash.  One parent (49281:01a44b79f36c) is "bad", and the other parent (52546:82c410fffaa8) is not a descendant of the regressor (49150:4d411039d112), so it is irrelevant that it is "good".  I think this crazy situation can only arise when looking to see when a bug went away, not when looking to see when a bug was introduced.

Comment 8

9 years ago
Which means this bug went away before the fix for bug 581263 landed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: [sg:critical][ccbr][fixed-in-tracemonkey by 581263] → [sg:critical][ccbr]
Group: core-security
Crash Signature: [@ JSScope::destroy]
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.