729812 - IonMonkey: Crash [@ js::GetObjectClass]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on ionmonkey revision 5a04fd69aa09 (run with --ion -n -m --ion-eager), tested on 64 bit:


function exploreProperties(obj) {
  var props = [];
  for (var o = obj; o; push  = Object.getPrototypeOf(o)) {
    props = props.concat(Object.getOwnPropertyNames(o));
  }
}
var c = [{}];
exploreProperties(c);

Comment 1

[Christian Holler (:decoder)]

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000412d38 in js::GetObjectClass (obj=0x7ffff0938500) at ../../jsfriendapi.h:364
364         return reinterpret_cast<const shadow::Object*>(obj)->shape->base->clasp;
Missing separate debuginfos, use: debuginfo-install libgcc-4.4.6-3.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
(gdb) bt
#0  0x0000000000412d38 in js::GetObjectClass (obj=0x7ffff0938500) at ../../jsfriendapi.h:364
#1  0x0000000000412e4a in js::IsObjectProxy (obj=0x7ffff0938500) at ../../jsproxy.h:149
#2  0x0000000000412eba in js::IsProxy (obj=0x7ffff0938500) at ../../jsproxy.h:161
#3  0x000000000044849c in JSObject::isProxy (this=0x7ffff0938500) at ../jsobjinlines.h:1414
#4  0x0000000000448620 in js::ObjectClassIs (obj=..., classValue=js::ESClass_Array, cx=0xcc6db0) at ../jsobjinlines.h:1921
#5  0x00000000004588a2 in js::array_concat (cx=0xcc6db0, argc=0, vp=0x7fffffffb160) at /home/ownhero/homes/mozilla/repos/ionmonkey/js/src/jsarray.cpp:2972
#6  0x00007ffff7f42585 in ?? ()
#7  0x00007ffff7f42419 in ?? ()
#8  0x00007fffffffb150 in ?? ()
#9  0x00007ffff7f4252a in ?? ()
#10 0x0000000000000200 in ?? ()

Comment 3

[Christian Holler (:decoder)]

Not a duplicate. JSBugMon reproduced this bug on tip (2c7e9bd43480) with testcase and options from comment 0.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Does it fail with the same assert?

Comment 5

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

> Does it fail with the same assert?

Yes. Tested with 64-bit js debug shell on IonMonkey changeset 5824c381df95 on Mac 10.7.

js> function exploreProperties(obj) {
  var props = [];
  for (var o = obj; o; push  = Object.getPrototypeOf(o)) {
    props = props.concat(Object.getOwnPropertyNames(o));
  }
}
js> var c = [{}];
js> exploreProperties(c);

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000100015fdf in js::GetObjectClass (obj=0x101f28a40) at jsfriendapi.h:378
378	    return reinterpret_cast<const shadow::Object*>(obj)->shape->base->clasp;
(gdb) call js_DumpBacktrace(CurrentIonContext()->cx)
#1            0x0   typein:4 (0x101f07180 @ 54)
#2    0x101840030   typein:8 (0x101f07438 @ 13)
(gdb) bt
#0  0x0000000100015fdf in js::GetObjectClass (obj=0x101f28a40) at jsfriendapi.h:378
#1  0x0000000100015d3a in js::IsProxy (obj=0x101f28a40) at jsproxy.h:169
#2  0x0000000100069055 in JSObject::isProxy (this=0x101f28a40) at jsobjinlines.h:1164
#3  0x000000010006050c in js::ObjectClassIs (obj=@0x101f28a40, classValue=js::ESClass_Array, cx=0x100f154f0) at jsobjinlines.h:1669
#4  0x0000000100075c94 in js::array_concat (cx=0x100f154f0, argc=0, vp=0x7fff5fbf62c0) at /Users/skywalker/Desktop/jsfunfuzz-dbg-64-im-91784-5824c381df95/compilePath/js/src/jsarray.cpp:2969
#5  0x0000000100ef0aa5 in ?? ()

Comment 6

[Christian Holler (:decoder)]

This seems to be a use-after-free condition:

(gdb) x /i $pc
=> 0x405010 <js::GetObjectClass(JSObject const*)+15>:   mov    (%rax),%rax
(gdb) info register rax
rax            0xdadadadadadadada       -2676586395008836902

Comment 7

[Bob Clary [:bc] (inactive)]

see Bug 752087

Comment 8

[Kannan Vijayan [:djvj]]

This is failing to repro for me, I've tried both debug and non-debug builds, on OSX 64-bit, rev e14efc51f562.

Comment 9

[Christian Holler (:decoder)]

It might be Linux only. Let's explicitly reconfirm that it's still there :)

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

I can actually reproduce this one, and for a GC bug this one wasn't too bad to find: we're not marking all the arguments of a native call's |vp|. In fact, we only recently got the ability to do this so this is a great test.

    if (footer->ionCode() == NULL) {
        size_t len = frame.numActualArgs();
        Value *vp = frame.exitFrame()->nativeVp();
        gc::MarkValueRootRange(trc, len, vp, "ion-native-args");

I think this should be numActualArgs() + 2 and nativeVp() - 2.

Comment 11

[Nicolas B. Pierron [:nbp]]

(In reply to David Anderson [:dvander] from comment #10)
> I can actually reproduce this one, and for a GC bug this one wasn't too bad
> to find: we're not marking all the arguments of a native call's |vp|. In
> fact, we only recently got the ability to do this so this is a great test.
> 
>     if (footer->ionCode() == NULL) {
>         size_t len = frame.numActualArgs();
>         Value *vp = frame.exitFrame()->nativeVp();
>         gc::MarkValueRootRange(trc, len, vp, "ion-native-args");
> 
> I think this should be and nativeVp() - 2.

I verified in CallNative, this is supposed to be “numActualArgs() + 2” and “nativeVp()”.
We don't have the “- 2” because it is correctly named “Vp” and not “Args”.

The detail is explained in CodeGenerator.cpp (CallNative)

Comment 12

[Kannan Vijayan [:djvj]]

Pierron is correct.  Checked in minor fix:

https://hg.mozilla.org/projects/ionmonkey/rev/7c58c07ee2af

Comment 13

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 14

[Christian Holler (:decoder)]

Not on m-c and too unreliable/slow to take as a test.