657633 - TI: Crash [@ JSCompartment::finalizeObjectArenaLists]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: shell testcase, unpack, chdir and read README

The attached testcase crashes on optimized TI revision 0cd135eb71a3 (see README for run instructions!), tested on 64 bit. Note that this test is really fragile, it is even affected by the length of the filenames in the test and by compile options (I was not able to reproduce this with --enable-gczeal for example).

Backtraces may look like this:

(gdb) bt
#0  0x00007faf5b858a75 in raise () from /lib/libc.so.6
#1  0x00007faf5b85c5c0 in abort () from /lib/libc.so.6
#2  0x00007faf5b8924fb in ?? () from /lib/libc.so.6
#3  0x00007faf5b89c5b6 in ?? () from /lib/libc.so.6
#4  0x00007faf5b8a2e83 in free () from /lib/libc.so.6
#5  0x00000000004767f2 in JSCompartment::finalizeObjectArenaLists (this=<value optimized out>, cx=<value optimized out>)
    at /home/decoder/LangFuzz/jaegermonkey/jsopt/src/jsobjinlines.h:164
#6  0x00000000004785e8 in GCCycle (cx=0x1651a60, comp=0x0, gckind=<value optimized out>) at /home/decoder/LangFuzz/jaegermonkey/jsopt/src/jsgc.cpp:2395
#7  0x0000000000478ada in js_GC (cx=0x1651a60, comp=0x0, gckind=GC_LAST_CONTEXT) at /home/decoder/LangFuzz/jaegermonkey/jsopt/src/jsgc.cpp:2747
#8  0x0000000000438623 in js_DestroyContext (cx=0x1651a60, mode=<value optimized out>) at /home/decoder/LangFuzz/jaegermonkey/jsopt/src/jscntxt.cpp:655
#9  0x00000000004047b2 in DestroyContext (cx=0x1651a60, withGC=true) at /home/decoder/LangFuzz/jaegermonkey/jsopt/src/shell/js.cpp:5826
#10 0x000000000040881a in main (argc=<value optimized out>, argv=0x7fff7f2a1810, envp=0x7fff7f2a1858) at /home/decoder/LangFuzz/jaegermonkey/jsopt/src/shell/js.cpp:6113

Sometimes this segfaults, sometimes it gets terminated by glibc.

Security lock because it is unclear if this is a TI problem or on TM as well, due to the fragile nature of this bug. If TM is affected, then it might be dangerous.

Comment 1

[Brian Hackett [Laid off!]]

Was not able to repro this, but after trying out the testcase and looking at stack traces which you posted on IRC, the problem is a crash after OOM when creating scripts (the reason it is so fragile).

With bug 637674 done we can now use -A to test OOM handling in the TI branch in a more exhaustive fashion.  I took this testcase and ran with -A in increments of 100 up to 10000, fixing the (fair number) of crashes we had from mishandling allocation failure in inference code.

The below rev gets rid of all of these, though there are still several crashes from failures in Yarr and the bytecode compiler.  The one which caused this bug showed up.  The problem is when creating a script we would assign to fun->u.i.script, create its type information, and destroy the script if that creation failed, leaving a dangling pointer on the JSObject to be double-deleted later (patch rearranges the order this is done).

The Yarr and compiler crashes should get reduced, filed and fixed so we can do more exhaustive testing of -A in both the TM and JM branches.

http://hg.mozilla.org/projects/jaegermonkey/rev/4dff743ec04d

Comment 2

[Christian Holler (:decoder)]

Test requires the tracer, marking verified as that is gone.