Summary: | REGRESSION(r118555): Assertion failure in JSC::DFG::AssemblyHelpers::decodedCodeMapFor on MathJax v2.0 sample | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Sergey Khodych <khodych> | ||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | UNCONFIRMED --- | ||||||||
Severity: | Critical | CC: | barraclough, dsd, efidler, eric, fpizlo, ggaren, mitya57, yong.li.webkit, ysangkok | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Sergey Khodych
2012-07-07 09:28:34 PDT
Created attachment 151144 [details]
MathJax v2.0 sample
It seems DFGOSRExitCompiler assumes setJITCodeMap is always called, however when LLINT isn't enabled, and canBeOptimized() = true, the jitCodeMap is left null. #if ENABLE(DFG_JIT) || ENABLE(LLINT) if (canBeOptimized() #if ENABLE(LLINT) || true #endif ) { CompactJITCodeMap::Encoder jitCodeMapEncoder; for (unsigned bytecodeOffset = 0; bytecodeOffset < m_labels.size(); ++bytecodeOffset) { if (m_labels[bytecodeOffset].isSet()) jitCodeMapEncoder.append(bytecodeOffset, patchBuffer.offsetOf(m_labels[bytecodeOffset])); } m_codeBlock->setJITCodeMap(jitCodeMapEncoder.finish()); } Filip? Created attachment 165632 [details]
a simple fix
Reproduced this crash on Fedora 18 (x86), webkitgtk-1.10.1. It happens while loading various pages such as http://tirania.org/blog/archive/2012/Oct-22.html and http://www.bbc.co.uk/weather/sg6 Program received signal SIGSEGV, Segmentation fault. 0xb611d7c9 in JSC::DFG::AssemblyHelpers::decodedCodeMapFor () from /lib/libjavascriptcoregtk-3.0.so.0 #0 0xb611d7c9 in JSC::DFG::AssemblyHelpers::decodedCodeMapFor () from /lib/libjavascriptcoregtk-3.0.so.0 #1 0xb615965d in JSC::DFG::OSRExitCompiler::compileExit () from /lib/libjavascriptcoregtk-3.0.so.0 #2 0xb615d649 in compileOSRExit () from /lib/libjavascriptcoregtk-3.0.so.0 #3 0xabf19866 in ?? () #4 0xb61d7c52 in JSC::Interpreter::executeCall () from /lib/libjavascriptcoregtk-3.0.so.0 #5 0xb62b4993 in JSC::call () from /lib/libjavascriptcoregtk-3.0.so.0 #6 0xbfffe3c4 in ?? () A more complete trace can be found in bug #102762. I've tested Yong's patch (above) and it solves the issue. Any chance of a review? Bump. This crash is still hurting, and there is a patch here waiting for review. I've tested it for the last few weeks, and it seems to be working fine. (In reply to comment #2) > It seems DFGOSRExitCompiler assumes setJITCodeMap is always called, however when LLINT isn't enabled, and canBeOptimized() = true, the jitCodeMap is left null. > > #if ENABLE(DFG_JIT) || ENABLE(LLINT) > if (canBeOptimized() > #if ENABLE(LLINT) > || true > #endif > ) { > CompactJITCodeMap::Encoder jitCodeMapEncoder; > for (unsigned bytecodeOffset = 0; bytecodeOffset < m_labels.size(); > ++bytecodeOffset) { > if (m_labels[bytecodeOffset].isSet()) > jitCodeMapEncoder.append(bytecodeOffset, > patchBuffer.offsetOf(m_labels[bytecodeOffset])); > } > m_codeBlock->setJITCodeMap(jitCodeMapEncoder.finish()); > } > > Filip? How can canBeOptimized() == true lead to jitCodeMap being null in the above code? Comment on attachment 165632 [details] a simple fix View in context: https://bugs.webkit.org/attachment.cgi?id=165632&action=review > Source/JavaScriptCore/jit/JIT.cpp:-764 > - if (canBeOptimized() > -#if ENABLE(LLINT) > - || true > -#endif > - ) { I think the problem here is that we should be emitting a code map when m_codeBlock->canCompileWithDFG() returns anything other than CannotCompile, whereas now we're just emitting the map when it returns CanCompile. This will happen since the other return value (ShouldProfile) indicates that the DFG may choose to inline the code block even if it doesn't compile it directly, and inlined code blocks better have jitCodeMaps. Could you do this more thorough fix instead? > > How can canBeOptimized() == true lead to jitCodeMap being null in the above code? Probably I meant "= false" and it is a typo. (In reply to comment #7) > I think the problem here is that we should be emitting a code map when m_codeBlock->canCompileWithDFG() returns anything other than CannotCompile, whereas now we're just emitting the map when it returns CanCompile. This will happen since the other return value (ShouldProfile) indicates that the DFG may choose to inline the code block even if it doesn't compile it directly, and inlined code blocks better have jitCodeMaps. > > Could you do this more thorough fix instead? Thanks. I would give a try. But I don't have enough time at the meantime. Also this issue does bite when LLINT is on. So I cannot promise to work on this any time soon. (In reply to comment #8) > > > > How can canBeOptimized() == true lead to jitCodeMap being null in the above code? > > Probably I meant "= false" and it is a typo. > > (In reply to comment #7) > > I think the problem here is that we should be emitting a code map when m_codeBlock->canCompileWithDFG() returns anything other than CannotCompile, whereas now we're just emitting the map when it returns CanCompile. This will happen since the other return value (ShouldProfile) indicates that the DFG may choose to inline the code block even if it doesn't compile it directly, and inlined code blocks better have jitCodeMaps. > > > > Could you do this more thorough fix instead? > > Thanks. I would give a try. But I don't have enough time at the meantime. Also this issue does bite when LLINT is on. So I cannot promise to work on this any time soon. oops, another typo. should be "does NOT bite when LLINT is on" |