Last Comment Bug 728674 - Use-after-free [@ js::mjit::Compiler::bytecodeInChunk]
: Use-after-free [@ js::mjit::Compiler::bytecodeInChunk]
[sg:critical] js-triage-needed [asan]...
: testcase, valgrind
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: ---
Assigned To: Christian Holler (:decoder)
Depends on: 728609
Blocks: langfuzz
  Show dependency treegraph
Reported: 2012-02-19 05:10 PST by Christian Holler (:decoder)
Modified: 2013-03-13 04:51 PDT (History)
7 users (show)
choller: in‑testsuite-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Test case for shell (see README file inside). (9.41 KB, application/x-compressed-tar)
2012-02-19 05:10 PST, Christian Holler (:decoder)
no flags Details

Description Christian Holler (:decoder) 2012-02-19 05:10:23 PST
Created attachment 598655 [details]
Test case for shell (see README file inside).

The attached test shows a use-after-free in Valgrind and ASan on mozilla-central revision 78fde7e54d92 (see README for running instructions). The test requires a threadsafe shell build (configure with --enable-debug --disable-optimize --enable-valgrind --enable-threadsafe --with-system-nspr) to reproduce, although the original test ( which I unfortunately did not backup :x ) even showed this behavior in a normal shell build and even crashed in a non-deterministic way.

That said, the test here is also non-deterministic, you might need to run it a few times to observe the error. I used ASan to reduce it to a few files but didn't minimize it further because it got even less reliable with smaller sizes.

Here's a Valgrind trace (before that, it also spews out some uninitialized use warnings, probably not related though):

==59936== Invalid read of size 4
==59936==    at 0x6D1AF8: js::mjit::Compiler::bytecodeInChunk(unsigned char*) (Compiler.h:526)
==59936==    by 0x6C1616: js::mjit::Compiler::jumpAndRun(JSC::AbstractMacroAssembler<JSC::X86Assembler>::Jump, unsigned char*, JSC::AbstractMacroAssembler<JSC::X86Assembler>::Jump*, bool*, bool) (Compiler.cpp:7132)
==59936==    by 0x6AACEE: js::mjit::Compiler::generateMethod() (Compiler.cpp:2212)
==59936==    by 0x6A2A8A: js::mjit::Compiler::performCompilation() (Compiler.cpp:543)
==59936==    by 0x6A17A8: js::mjit::Compiler::compile() (Compiler.cpp:159)
==59936==    by 0x6A3E25: js::mjit::CanMethodJIT(JSContext*, JSScript*, unsigned char*, bool, js::mjit::CompileRequest) (Compiler.cpp:996)
==59936==    by 0x750CDD: UncachedInlineCall(js::VMFrame&, js::InitialFrameFlags, void**, bool*, unsigned int) (InvokeHelpers.cpp:322)
==59936==    by 0x75146A: js::mjit::stubs::UncachedCallHelper(js::VMFrame&, unsigned int, bool, js::mjit::stubs::UncachedCallResult*) (InvokeHelpers.cpp:471)
==59936==    by 0x738CFE: CallCompiler::update() (MonoIC.cpp:960)
==59936==    by 0x733D12: js::mjit::ic::Call(js::VMFrame&, js::mjit::ic::CallICInfo*) (MonoIC.cpp:1018)
==59936==    by 0x69C038: ??? (MethodJIT.cpp:160)
==59936==    by 0x69C30F: js::mjit::EnterMethodJIT(JSContext*, js::StackFrame*, void*, JS::Value*, bool) (MethodJIT.cpp:1053)
==59936==  Address 0x809d5cc is 108 bytes inside a block of size 128 free'd
==59936==    at 0x4C282ED: free (vg_replace_malloc.c:366)
==59936==    by 0x403F4B: js_free (Utility.h:152)
==59936==    by 0x41258C: js::Foreground::free_(void*) (Utility.h:566)
==59936==    by 0x4C8ADA: js::GCHelperThread::freeElementsAndArray(void**, void**) (jsgc.h:1467)
==59936==    by 0x4C3BF7: js::GCHelperThread::doSweep() (jsgc.cpp:2547)
==59936==    by 0x4C3579: js::GCHelperThread::threadLoop() (jsgc.cpp:2403)
==59936==    by 0x4C34DF: js::GCHelperThread::threadMain(void*) (jsgc.cpp:2382)
==59936==    by 0x547D012: ??? (in /usr/lib/
==59936==    by 0x4E35D8B: start_thread (pthread_create.c:304)
==59936==    by 0x611C04C: clone (clone.S:112)
Comment 1 Brian Hackett (:bhackett) 2012-02-27 07:36:09 PST
I haven't been able to reproduce this.  The call stack suggests that the compiler's script is being freed out from under it, which doesn't make any sense at all.  Can you reproduce this on other revisions?  When did it appear?
Comment 2 Bill McCloskey (:billm) 2012-02-27 08:23:51 PST
This sorta sounds like a dupe of bug 728609.
Comment 3 David Mandelin [:dmandelin] 2012-03-02 11:32:48 PST
Closing as dup based on comment 1 and comment 2.
Comment 4 Daniel Veditz [:dveditz] 2012-03-08 13:59:57 PST
Reassigning to :decoder for investigation of which releases are actually affected, to know which branches we need to take the patch from bug 728609. Also to verify it as fixed in Firefox 13
Comment 5 Christian Holler (:decoder) 2013-03-13 04:51:08 PDT
Only an unreliable test available here, marking in-testsuite-.

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