I have a crash on TI revision 3cf701fb5962 (options -j -m -n), but wasn't able so far to get the test out of the driver. Posting the stack here first on request of bhackett. If that doesn't suffice, I'll work on the test: ==2135== Invalid read of size 8 ==2135== at 0x441E76: JSScript::ensureHasTypes(JSContext*) (jsinferinlines.h:1298) ==2135== by 0x4E16D8: TypeConstraintPropagateThis::newType(JSContext*, js::types::TypeSet*, js::types::Type) (jsinfer.cpp:1203) ==2135== by 0x4418EB: js::types::TypeCompartment::resolvePending(JSContext*) (jsinferinlines.h:746) ==2135== by 0x4F0E66: js::types::TypeSet::add(JSContext*, js::types::TypeConstraint*, bool) (jsinfer.cpp:413) ==2135== by 0x4E046A: js::types::TypeSet::addPropagateThis(JSContext*, JSScript*, unsigned char*, js::types::Type) (jsinfer.cpp:707) ==2135== by 0x4E6B1C: js::analyze::ScriptAnalysis::analyzeTypesBytecode(JSContext*, unsigned int, js::analyze::ScriptAnalysis::TypeInferenceState&) (jsinfer.cpp:3309) ==2135== by 0x4E8BE7: js::analyze::ScriptAnalysis::analyzeTypes(JSContext*) (jsinfer.cpp:3906) ==2135== by 0x4F0992: JSScript::ensureRanInference(JSContext*) (jsinferinlines.h:1321) ==2135== by 0x6A72C1: js::mjit::Compiler::checkAnalysis(JSScript*) (Compiler.cpp:189) ==2135== by 0x6A804B: js::mjit::Compiler::performCompilation(js::mjit::JITScript**) (Compiler.cpp:509) ==2135== by 0x6A71BF: js::mjit::Compiler::compile() (Compiler.cpp:163) ==2135== by 0x6A8A5C: js::mjit::TryCompile(JSContext*, js::StackFrame*) (Compiler.cpp:627) ==2135== Address 0xd0 is not stack'd, malloc'd or (recently) free'd
Hmm, can you give me a full test?
Created attachment 552760 [details] Test case for shell (see README file inside). Here is the test case (see README to run it), but beware that it might be fragile (and/or only work on Linux/64 bit).
When a GC is triggered during the middle of inference, analysis or compilation, we pin all scripts and type objects in the compartment so that information referred to by the type info is not destroyed while in use (type info generally holds only weak references). This omitted pinning JS objects with singleton types, which can appear in type sets directly. One such object was collected, and later reallocated as a partially initialized function (the function was created, then abandoned after a syntax error while parsing), appearing zombie-like the next time the type set still containing it was used. http://hg.mozilla.org/projects/jaegermonkey/rev/044290f5a31d
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.