779124 - IonMonkey: Assertion failure: info.isValid(), at jsinfer.cpp:2059 with memory corruption

Status: RESOLVED DUPLICATE of bug 780274

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: Testcase for shell

The attached testcase asserts on ionmonkey revision 54f9ee5403f0 (run with --ion -n -m --ion-eager).

Comment 1

[Christian Holler (:decoder)]

Running in an opt-build gets me:

*** glibc detected *** /srv/repos/ionmonkey/js/src/opt32/js: corrupted double-linked list: 0x096de9a0 ***

and the assertion changed a few times, so it's very likely some memory corruption. Running the opt-build in valgrind gives me a few of these:

==23089== Invalid read of size 4
==23089==    at 0x832B0F6: js::ion::Invalidate(js::FreeOp*, js::Vector<js::types::CompilerOutput, 0u, js::TempAllocPolicy> const&, bool) (IonCode.h:372)
==23089==    by 0x80CC24C: js::types::TypeCompartment::processPendingRecompiles(js::FreeOp*) (jsinfer.cpp:2072)
==23089==    by 0x80CC728: js::types::AutoEnterTypeInference::~AutoEnterTypeInference() (jsinferinlines.h:275)
==23089==    by 0x80D22EE: js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&) (jsinfer.cpp:4919)
==23089==    by 0x80EC3CE: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinferinlines.h:758)
==23089==    by 0x8CFB0CF: ???
==23089==  Address 0x8d25ebc is 100 bytes inside a block of size 724 free'd
==23089==    at 0x77A020B: free (vg_replace_malloc.c:366)
==23089==    by 0x83293BF: js::ion::FinishInvalidation(js::FreeOp*, JSScript*) (Utility.h:174)
==23089==    by 0x8090A71: JSCompartment::discardJitCode(js::FreeOp*) (jscompartment.cpp:518)
==23089==    by 0x8092291: JSCompartment::sweep(js::FreeOp*, bool) (jscompartment.cpp:538)
==23089==    by 0x80C5DCC: IncrementalCollectSlice(JSRuntime*, long long, js::gcreason::Reason, js::JSGCInvocationKind) (jsgc.cpp:3581)
==23089==    by 0x80C7A3B: GCCycle(JSRuntime*, bool, long long, js::JSGCInvocationKind, js::gcreason::Reason) (jsgc.cpp:4172)
==23089==    by 0x80C7F89: Collect(JSRuntime*, bool, long long, js::JSGCInvocationKind, js::gcreason::Reason) (jsgc.cpp:4276)
==23089==    by 0x80C8215: js::gc::RunDebugGC(JSContext*) (jsgc.cpp:4568)
==23089==    by 0x80D0410: js::types::TypeCompartment::newTypeObject(JSContext*, JSScript*, JSProtoKey, JSObject*, bool, bool) (jsgcinlines.h:411)
==23089==    by 0x80D4348: js::types::TypeCompartment::newAllocationSiteTypeObject(JSContext*, js::types::AllocationSiteKey) (jsinfer.cpp:1909)
==23089==    by 0x80DF76B: js::types::TypeScript::InitObject(JSContext*, JSScript*, unsigned char*, JSProtoKey) (jsinferinlines.h:721)
==23089==    by 0x80E1465: TypeConstraintCall::newType(JSContext*, js::types::TypeSet*, js::types::Type) (jsinfer.cpp:1148)

Comment 2

[Nicolas B. Pierron [:nbp]]

This bug sounds related to Bug 777788.  The previous valgrind backtrace seems to report that the pendingRecompiles is using copies of CompilerOutput, which means that if the script has been invalidated while the copy was in the pending list, the info.isValid() assertion does not hold anymore.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

jsfunfuzz finds this pretty often as well.

Comment 4

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 2169bca0c9a5).

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

See bug 780274 for another testcase.

Comment 6

[Nicolas B. Pierron [:nbp]]

The patch for Bug 780274 applied on top of ionmonkey revision 54f9ee5403f0 seems to fix this issue.