Last Comment Bug 656753 - TI: Assertion failure: m_pools.empty(), at ./assembler/jit/ExecutableAllocator.h:180
: TI: Assertion failure: m_pools.empty(), at ./assembler/jit/ExecutableAllocato...
: 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-12 14:08 PDT by Christian Holler (:decoder)
Modified: 2013-01-14 08:14 PST (History)
5 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

shell testcase, unpack, chdir and run main.js with options "-j -n -m -a" (2.06 KB, application/x-compressed-tar)
2011-05-12 14:08 PDT, Christian Holler (:decoder)
no flags Details

Description User image Christian Holler (:decoder) 2011-05-12 14:08:23 PDT
Created attachment 532025 [details]
shell testcase, unpack, chdir and run main.js with options "-j -n -m -a"

The attached testcase asserts on TI revision 09461ee64436 (run with -j -m -n -a),
tested on 64 bit. This is another very fragile test.
Comment 1 User image Christian Holler (:decoder) 2011-05-12 14:11:00 PDT
Stack trace:

Assertion failure: m_pools.empty(), at ./assembler/jit/ExecutableAllocator.h:180
[New Thread 0x7f956855b720 (LWP 26763)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f956855b720 (LWP 26763)]
0x00007f956814f7bb in raise () from /lib/
(gdb) bt
#0  0x00007f956814f7bb in raise () from /lib/
#1  0x00000000005cc9c8 in JS_Assert (s=0x7bde3b "m_pools.empty()", file=0x7bddf0 "./assembler/jit/ExecutableAllocator.h", ln=180)
    at /home/decoder/LangFuzz/jaegermonkey/js/src/jsutil.cpp:89
#2  0x000000000046f555 in ~ExecutableAllocator (this=0x2091120) at ./assembler/jit/ExecutableAllocator.h:180
#3  0x000000000046fb17 in js::Foreground::delete_<JSC::ExecutableAllocator> (p=0x2091120) at ./jsutil.h:498
#4  0x00000000006907ed in js::mjit::JaegerCompartment::Finish (this=0x2091080) at /home/decoder/LangFuzz/jaegermonkey/js/src/methodjit/MethodJIT.cpp:847
#5  0x000000000046f58c in ~JaegerCompartment (this=0x2091080) at /home/decoder/LangFuzz/jaegermonkey/js/src/methodjit/MethodJIT.h:361
#6  0x000000000046fb44 in js::Foreground::delete_<js::mjit::JaegerCompartment> (p=0x2091080) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsutil.h:498
#7  0x000000000046cd78 in ~JSCompartment (this=0x2036dd0) at /home/decoder/LangFuzz/jaegermonkey/js/src/jscompartment.cpp:103
#8  0x00000000004c2ce7 in JSContext::delete_<JSCompartment> (this=0x2036880, p=0x2036dd0) at /home/decoder/LangFuzz/jaegermonkey/js/src/jscntxt.h:1318
#9  0x00000000004bafc5 in SweepCompartments (cx=0x2036880, gckind=GC_LAST_CONTEXT) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsgc.cpp:2238
#10 0x00000000004bb769 in MarkAndSweep (cx=0x2036880, comp=0x0, gckind=GC_LAST_CONTEXT) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsgc.cpp:2425
#11 0x00000000004bb9fa in GCCycle (cx=0x2036880, comp=0x0, gckind=GC_LAST_CONTEXT) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsgc.cpp:2674
#12 0x00000000004bbbd8 in js_GC (cx=0x2036880, comp=0x0, gckind=GC_LAST_CONTEXT) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsgc.cpp:2745
#13 0x0000000000467e74 in js_DestroyContext (cx=0x2036880, mode=JSDCM_FORCE_GC) at /home/decoder/LangFuzz/jaegermonkey/js/src/jscntxt.cpp:655
#14 0x000000000042a355 in JS_DestroyContext (cx=0x2036880) at /home/decoder/LangFuzz/jaegermonkey/js/src/jsapi.cpp:1034
#15 0x0000000000411acd in DestroyContext (cx=0x2036880, withGC=true) at /home/decoder/LangFuzz/jaegermonkey/js/src/shell/js.cpp:5824
#16 0x00000000004122a2 in main (argc=5, argv=0x7fff55ac0a50, envp=0x7fff55ac0a80) at /home/decoder/LangFuzz/jaegermonkey/js/src/shell/js.cpp:6107
Comment 2 User image Brian Hackett (:bhackett) 2011-05-14 14:32:38 PDT
If we recompile a frame from inside a native stub (either the native itself or SplatApplyArgs), we orphan the stub until the call finishes and we rejoin to the interpoline.  If the native throws, we rejoined to the throwpoline instead, which didn't release the pool reference and leaked it.  The fix has us check for a reference to the orphaned pools in both the interpoline and throwpoline.
Comment 3 User image Christian Holler (:decoder) 2013-01-14 08:14:16 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/recompile/bug656753.js.

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