655769 - TI: Assertion failure: (ptrBits & 0x7) == 0, at ../jsval.h:702

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: Test case for shell (run with -n -a)

The attached testcase asserts on TI revision 325744fbf7f0 (run with -n -a),
tested on 64 bit. This is a very fragile test and it needs ~20 seconds to assert.

Comment 1

[Christian Holler (:decoder)]

This test doesnt work anymore on tip, but the fuzzer found a new test with the same assertion so I assume the cause is still there. If you need the newer test for tip, let me know and I'll reduce.

Comment 2

[Brian Hackett [Laid off!]]

I wasn't able to repro this test on OSX x64 under the given changeset (maybe I need to be using a Linux VM).  If the new test is less fragile it would be good to have.

Comment 3

[Christian Holler (:decoder)]

Ok I reduced the new test and it changed from the assert to a crash. The test is as follows (options are -m -n -a), tested on TI rev 015bd3ff1be6 (64 bit):

function Day(t) {
    Math.floor()
}
function MakeDate(day, time) {}
function TimeClip(t) {
    ToInteger()
}
function ToInteger(t) Number;
(0, 0, 0, 0, UTCDateFromTime(), LocalDateFromTime(SetUTCMinutes(2208988800000, 59, 999)));
function MyDate() {
    this.UTCDate++
}
function LocalDateFromTime(t) {
    MyDateFromTime()
}
function UTCDateFromTime(t) {
    MyDateFromTime()
}
function MyDateFromTime(t) {
    d = new MyDate
}
function SetUTCMinutes(t, min, sec, ms) {
    var TIME = t;
    var MIN = min;
    var SEC = sec == 0 ? TIME : sec;
    var MS = ms == 0 ? msFromTime : ms;
    var RESULT5 = (TIME, MS);
    TimeClip(MakeDate(Day(), RESULT5))
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa676621720 (LWP 1222)]
0x0000000000413944 in JSObject::getType (this=0x7fa600000000) at ./jsobj.h:741
741         js::types::TypeObject* getType() const { return type; }
(gdb) bt
#0  0x0000000000413944 in JSObject::getType (this=0x7fa600000000) at ./jsobj.h:741
#1  0x000000000078ef38 in MonitorArithmeticOverflow (f=@0x7fffcab90830, v=@0x7fa6750d1238) at /home/decoder/LangFuzz/jaegermonkey/js/src/methodjit/StubCalls.cpp:1090
#2  0x000000000078f527 in js::mjit::stubs::Sub (f=@0x7fffcab90830) at /home/decoder/LangFuzz/jaegermonkey/js/src/methodjit/StubCalls.cpp:1183
#3  0x00007fa6750c3c01 in ?? ()
#4  0x00007fa6750c1080 in ?? ()
#5  0x0000000001e98210 in ?? ()
#6  0x0000000000000000 in ?? ()

Comment 4

[Brian Hackett [Laid off!]]

Cool, I can repro the crash now.

Comment 5

[Brian Hackett [Laid off!]]

Hmm, this most recent testcase is a dupe of bug 655998, but I suspect that is masking the original problem.  What does the stack trace look like?

Comment 6

[Christian Holler (:decoder)]

Okay I think the issues here are clearly two separate ones. While the second test case is fixed, the first reproduces (again) on TI revision 09461ee64436 with options -m -n -a. Also the traces are entirely different. Here is a backtrace for the first test case. If you cannot reproduce under Mac and need more, let me know:

Assertion failure: (ptrBits & 0x7) == 0, at ../jsval.h:702
[New Thread 0x7f47ed886720 (LWP 18485)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f47ed886720 (LWP 18485)]
0x00007f47ed47a7bb in raise () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007f47ed47a7bb in raise () from /lib/libpthread.so.0
#1  0x00000000005cc9c8 in JS_Assert (s=0x7a8392 "(ptrBits & 0x7) == 0", file=0x7a82bb "../jsval.h", ln=702) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsutil.cpp:89
#2  0x000000000040446b in JSVAL_TO_OBJECT_IMPL (l=
      {asBits = 18446744069414584321, debugView = {payload47 = 140733193388033, tag = 131071}, s = {payload = {i32 = 1, u32 = 1, why = JS_ARGS_HOLE, word = 18446744069414584321}}, asDouble = -nan(0xfffff00000001), asPtr = 0xffffffff00000001}) at ../jsval.h:702
#3  0x00000000004136ee in js::Value::toObject (this=0x7fffe1e14530) at ./jsvalue.h:620
#4  0x00000000005ab0e8 in js::ValueToStringBufferSlow (cx=0x196c880, arg=@0x23aa300, sb=@0x7fffe1e14660) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsstr.cpp:3931
#5  0x000000000045696f in js::ValueToStringBuffer (cx=0x196c880, v=@0x23aa300, sb=@0x7fffe1e14660) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsstrinlines.h:255
#6  0x000000000044b9df in array_toString_sub (cx=0x196c880, obj=0x7f47ec202190, locale=0, sepstr=0x7f47ec200020, rval=0x7f47ec3360b0)
    at /home/decoder/LangFuzz/jaegermonkey/js/src/jsarray.cpp:1416
#7  0x000000000044c8d4 in array_join (cx=0x196c880, argc=1, vp=0x7f47ec3360b0) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsarray.cpp:1652
#8  0x00000000004f117c in js::CallJSNative (cx=0x196c880, native=0x44c7d6 <array_join>, argc=1, vp=0x7f47ec3360b0)
    at /home/decoder/LangFuzz/jaegermonkey/js/src/jscntxtinlines.h:293
#9  0x0000000000714d6d in CallCompiler::generateNativeStub (this=0x7fffe1e15220) at /home/decoder/LangFuzz/jaegermonkey/js/src/methodjit/MonoIC.cpp:833
#10 0x000000000070f7a7 in js::mjit::ic::NativeCall (f=@0x7fffe1e15260, ic=0x22cfa78) at /home/decoder/LangFuzz/jaegermonkey/js/src/methodjit/MonoIC.cpp:1102
#11 0x00007f47ec333707 in ?? ()
#12 0x00007f47ec333596 in ?? ()
#13 0x00007f47ecab4e40 in ?? () from /lib/libc.so.6
#14 0x00007fffe1e169a0 in ?? ()
#15 0x0000000000000000 in ?? ()

Comment 7

[Brian Hackett [Laid off!]]

Was able to repro this in a Linux x64 VM.  The problem is that an optimization in Array.join which came into JM a few weeks ago via a merge from TM was still using the capacity of a dense array for scanning elements rather than the initialized length, and eventually started reading uninitialized values.

http://hg.mozilla.org/projects/jaegermonkey/rev/22a0b177d821