626610 - Crash [@ js::Oracle::Oracle]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: testcase

Attached testcase (not fully reduced as it's very fragile) crashes js opt shell at js::Oracle::Oracle, but merely shows the malloc error (shown below) on js debug shell, without -m or -j.

Related to bug 624645 or bug 624878? It showed the same symptoms as bug 624645 before bug 624878 landed.

Tested on:
http://hg.mozilla.org/tracemonkey/rev/4046ef71ddc2


__defineSetter__("window", Object.defineProperties)
for (a = 0; a < 2 && window ? 3951632192 : Math; ++a) {
     evalcx('')
}

is another testcase that does not crash but shows the same malloc errors.

===

opt shell stdout:

js-opt-32-tm-darwin(68681) malloc: *** mmap(size=16777216) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
js-opt-32-tm-darwin(68681) malloc: *** mmap(size=16777216) failed (error code=12)
*** error: can't allocate region
*** 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: 0x00000000
0x00190c13 in js::Oracle::Oracle ()
(gdb) bt
#0  0x00190c13 in js::Oracle::Oracle ()
#1  0x0019301c in js::InitJIT ()
#2  0x00036acd in JSCompartment::init ()
#3  0x00071f7d in js::gc::NewCompartment ()
#4  0x0001c6ce in JS_NewCompartmentAndGlobalObject ()
#5  0x00009a9d in EvalInContext ()
#6  0x0008f522 in js::Interpret ()
#7  0x0009cc1d in js::Execute ()
#8  0x00019438 in JS_ExecuteScript ()
#9  0x00006ba9 in Process ()
#10 0x0000afc2 in Shell ()
#11 0x0000b55f in main ()
(gdb) x/i $eip
0x190c13 <_ZN2js6OracleC2Ev+563>:       mov    %eax,(%esi,%ecx,4)
(gdb) x/b $eax
0x0:    Cannot access memory at address 0x0
(gdb) x/b $esi
0x0:    Cannot access memory at address 0x0
(gdb) x/b $ecx
0x0:    Cannot access memory at address 0x0

Comment 1

[David Mandelin [:dmandelin]]

Looks like an OOM crash, hopefully fairly easy to fix.

Comment 2

[Nicholas Nethercote [inactive]]

Bug 624878 landed yesterday, it should have fixed this.  Gary, can you try again with an up-to-date TraceMonkey build?

Comment 3

[David Mandelin [:dmandelin]]

I still get this as of http://hg.mozilla.org/tracemonkey/rev/75354982793c.

Comment 4

[David Mandelin [:dmandelin]]

(In reply to comment #3)
> I still get this as of http://hg.mozilla.org/tracemonkey/rev/75354982793c.

Actually, I get a different error though:

Assertion failure: !entered && i < mLength, at c:\sources\tracemonkey\js\src\jsvector.h:304

At first I thought it was just a unix/windows thing, but maybe that assert is a residual bug after the other was fixed.

Comment 5

[Nicholas Nethercote [inactive]]

Completely different bug, by the looks of it.  Can you file a new bug, including a stack trace?  Thanks.

Comment 6

[David Mandelin [:dmandelin]]

Yes, it is a new bug. I can't get a stack trace for it because I can only repro it on Windows, where the debugger fails to attach to the crashing process. Also, opt builds run fine, and correctly generate an OOM error. So, seems like a relatively minor bug.

Comment 7

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

This bug was not a dupe of bug 624878 - it instead was fixed by bug 623428 - which landed later than bug 624878.

===

Due to skipped revisions, the first good revision could be any of:
changeset:   60651:f2c9c558e51e
user:        Nicholas Nethercote
date:        Tue Jan 18 14:58:34 2011 -0800
summary:     Bug 623428 - TM: avoid bloat caused by multiple mReserve arrays in VMAllocator (NJ-specific part).  r=edwsmith.

changeset:   60652:b9ea6138a9e5
user:        Nicholas Nethercote
date:        Tue Jan 18 15:04:48 2011 -0800
summary:     Update nanojit-import-rev stamp.

changeset:   60653:d90128361cb8
user:        Nicholas Nethercote
date:        Tue Jan 18 15:05:43 2011 -0800
summary:     Bug 623428 - TM: avoid bloat caused by multiple mReserve arrays in VMAllocator (TM-specific part).  r=gal.

Comment 8

[Nicholas Nethercote [inactive]]

That's surprising.  I will have to dig into this a bit more to understand what happened.