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);

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 ?? ()

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

Does it fail with the same assert?

> 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 ?? ()

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

see Bug 752087

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

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

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.

(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)

Pierron is correct. Checked in minor fix: https://hg.mozilla.org/projects/ionmonkey/rev/7c58c07ee2af

JSBugMon: This bug has been automatically verified fixed.

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