[Webkit-unassigned] [Bug 150580] New: REGRESSION (r191360): Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::FTL:: + 386

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=150580

            Bug ID: 150580
           Summary: REGRESSION (r191360): Crash:
                    com.apple.WebKit.WebContent at
                    com.apple.JavaScriptCore: JSC::FTL:: + 386
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: msaboff at apple.com

To reproduce:
1. go to maps.google.com
2. type "Paris" in search field, submit
3. type "London" in search field, submit

In the debugger, I can see that we are crashing at:
'WebCore: Worker', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef)
    frame #0: 0x000000010c97b877 JavaScriptCore`::WTFCrash() + 39 at Assertions.cpp:321
  * frame #1: 0x000000010c32fb6b JavaScriptCore`JSC::FTL::(anonymous namespace)::recoveryFor(value=0x0000000130bcff40, record=0x000000012caf1660, stackmaps=0x000000012f6cad80) + 539 at FTLJSTailCall.cpp:79
    frame #2: 0x000000010c32eeae JavaScriptCore`JSC::FTL::JSTailCall::emit(this=0x000000013407ef00, jitCode=0x000000012f6cac80, jit=0x00007000007b8c08) + 830 at FTLJSTailCall.cpp:261
    frame #3: 0x000000010c2fb313 JavaScriptCore`JSC::FTL::fixFunctionBasedOnStackMaps(state=0x00007000007ba788, codeBlock=0x00000001314c8700, jitCode=0x000000012f6cac80, generatedFunction=0x0000409246d78ee0, recordMap={ size = 0, capacity = 0 })(JSC::ExecState*), WTF::HashMap<unsigned int, WTF::Vector<JSC::FTL::StackMaps::RecordAndIndex, 0ul, WTF::CrashOnOverflow, 16ul>, WTF::IntHash<unsigned int>, WTF::UnsignedWithZeroKeyHashTraits<unsigned int>, WTF::HashTraits<WTF::Vector<JSC::FTL::StackMaps::RecordAndIndex, 0ul, WTF::CrashOnOverflow, 16ul> > >&) + 15171 at FTLCompile.cpp:691
    frame #4: 0x000000010c2f6e63 JavaScriptCore`JSC::FTL::compile(state=0x00007000007ba788, safepointResult=0x00007000007ba8f8) + 4259 at FTLCompile.cpp:920
...

The RELEASE_ASSERT in question is found in:
ValueRecovery recoveryFor(const ExitValue& value, StackMaps::Record& record, StackMaps& stackmaps)
{
    switch (value.kind()) {
...
    case ExitValueArgument: {
        auto location =
            FTL::Location::forStackmaps(&stackmaps, record.locations[value.exitArgument().argument()]);
        auto format = value.exitArgument().format();

        switch (location.kind()) {
        case Location::Register:
            // We handle the addend outside
            return ValueRecovery::inRegister(location.dwarfReg().reg(), format);

        case Location::Indirect:
            // Oh LLVM, you crazy...
            RELEASE_ASSERT(location.dwarfReg().reg() == Reg(MacroAssembler::framePointerRegister));
 ==>        RELEASE_ASSERT(!(location.offset() % sizeof(void*)));
            return ValueRecovery::displacedInJSStack(VirtualRegister { static_cast<int>(location.offset() / sizeof(void*)) }, format);

        case Location::Constant:
            return ValueRecovery::constant(JSValue::decode(location.constant()));

        default:
            RELEASE_ASSERT_NOT_REACHED();
        }
    }
...
}

The location (from elsewhere in the debug output) is (Indirect, %rbp, off:-84, size:4).  Clearly the address is not 8 byte aligned.  It is a 4 byte value that is naturally aligned.  Looks like we need teach the call frame shuffler to handle such cases.  Currently the FTL tail call code allows 32 bit integers and booleans to be saved on the stack as 32 bit values.  The Call Frame shuffler properly boxes these values, but represents their stack location as a VirtualRegister.

In preparing a test case, I ran across another related issue.
ASSERTION FAILED: !isUndecided()
/Volumes/Data/src/webkit/Source/JavaScriptCore/jit/CallFrameShuffler.cpp(309) : void JSC::CallFrameShuffler::extendFrameIfNeeded()
1   0x10909b870 WTFCrash
2   0x10859a044 JSC::CallFrameShuffler::extendFrameIfNeeded()
3   0x108599ede JSC::CallFrameShuffler::spill(JSC::CachedRecovery&)
4   0x10859fa7f void JSC::CallFrameShuffler::ensureRegister<JSC::CallFrameShuffler::ensureGPR()::'lambda'(JSC::CachedRecovery const&)>(JSC::CallFrameShuffler::ensureGPR()::'lambda'(JSC::CachedRecovery const&) const&)
5   0x10859f8fd JSC::CallFrameShuffler::ensureGPR()
6   0x10859d069 JSC::CallFrameShuffler::acquireGPR()
7   0x10859aed4 JSC::CallFrameShuffler::prepareForTailCall()
8   0x108a4f7da JSC::FTL::JSTailCall::emit(JSC::FTL::JITCode&, JSC::CCallHelpers&)
...

I'll address that issue with this bug as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151026/11e72c2c/attachment-0001.html>