As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 655769 - TI: Assertion failure: (ptrBits & 0x7) == 0, at ../jsval.h:702
: TI: Assertion failure: (ptrBits & 0x7) == 0, at ../jsval.h:702
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
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:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

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 User image 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 User image 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 User image 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 User image 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) {
function MakeDate(day, time) {}
function TimeClip(t) {
function ToInteger(t) Number;
(0, 0, 0, 0, UTCDateFromTime(), LocalDateFromTime(SetUTCMinutes(2208988800000, 59, 999)));
function MyDate() {
function LocalDateFromTime(t) {
function UTCDateFromTime(t) {
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))


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 User image Brian Hackett (:bhackett) 2011-05-10 15:08:32 PDT
Cool, I can repro the crash now.
Comment 5 User image 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 User image 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/
(gdb) bt
#0  0x00007f47ed47a7bb in raise () from /lib/
#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/
#14 0x00007fffe1e169a0 in ?? ()
#15 0x0000000000000000 in ?? ()
Comment 7 User image 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.

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