Last Comment Bug 655769 - TI: Assertion failure: (ptrBits & 0x7) == 0, at ../jsval.h:702
: TI: Assertion failure: (ptrBits & 0x7) == 0, at ../jsval.h:702
Status: RESOLVED FIXED
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: ---
Assigned To: general
:
Mentors:
Depends on:
Blocks: infer-regress langfuzz
  Show dependency treegraph
 
Reported: 2011-05-09 11:10 PDT by Christian Holler (:decoder)
Modified: 2011-08-05 00:54 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case for shell (run with -n -a) (1.65 KB, application/javascript)
2011-05-09 11:10 PDT, Christian Holler (:decoder)
no flags Details

Description Christian Holler (:decoder) 2011-05-09 11:10:15 PDT
Created attachment 531089 [details]
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) 2011-05-10 13:12:11 PDT
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 (:bhackett) 2011-05-10 13:16:07 PDT
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) 2011-05-10 14:56:15 PDT
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 (:bhackett) 2011-05-10 15:08:32 PDT
Cool, I can repro the crash now.
Comment 5 Brian Hackett (:bhackett) 2011-05-11 07:26:53 PDT
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) 2011-05-12 11:40:55 PDT
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 (:bhackett) 2011-05-14 10:41:39 PDT
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

Note You need to log in before you can comment on or make changes to this bug.