Summary: | [Win] JavaScript JIT crash (with DFG enabled). | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | peavo | ||||||
Component: | JavaScriptCore | Assignee: | Michael Saboff <msaboff> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | darin, msaboff, roger_fong | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
peavo
2013-11-20 13:26:37 PST
Created attachment 217474 [details]
Patch
I'm not sure that this is the right way to fix it, but it does fix the crash I've been having. Comment on attachment 217474 [details]
Patch
What this means is that there's some Windows-specific DFG code that uses "nonArgGPR0" when it should have used "regT0". Your patch hides the bug by making nonArgGPR0 equal to regT0. That's not a good long-term solution because the two registers can't be equal on all platforms.
*** Bug 124683 has been marked as a duplicate of this bug. *** (In reply to comment #0) > I'm currently getting a reproducible crash in JIT code with DFG enabled. > The crash is an access reading violation. > > The offending instruction is shown in the disassembly below: > > 058F204B jmp 05501EA3 > 058F2050 mov esi,eax > 058F2052 mov eax,0FFFFFFFBh < The value assigned to eax causing the access violation is set here, I think. > 058F2057 mov ebx,5501EA3h > 058F205C push ebx > 058F205D jmp 058F2080 The code above is generated by linkClosureCall(): … AssemblyHelpers::Jump done = stubJit.jump(); slowPath.link(&stubJit); stubJit.move(calleeGPR, GPRInfo::nonArgGPR0); #if USE(JSVALUE32_64) stubJit.move(CCallHelpers::TrustedImm32(JSValue::CellTag), GPRInfo::nonArgGPR1); #endif stubJit.move(CCallHelpers::TrustedImmPtr(callLinkInfo.callReturnLocation.executableAddress()), GPRInfo::nonArgGPR2); stubJit.restoreReturnAddressBeforeReturn(GPRInfo::nonArgGPR2); AssemblyHelpers::Jump slow = stubJit.jump(); .. > 058F2062 add byte ptr [eax],al > 058F2064 add byte ptr [eax],al > 058F2066 add byte ptr [eax],al > 058F2068 add byte ptr [eax],al > 058F206A add byte ptr [eax],al > 058F206C add byte ptr [eax],al > 058F206E add byte ptr [eax],al > 058F2070 add byte ptr [eax],al > 058F2072 add byte ptr [eax],al > 058F2074 add byte ptr [eax],al > 058F2076 add byte ptr [eax],al > 058F2078 add byte ptr [eax],al > 058F207A add byte ptr [eax],al > 058F207C add byte ptr [eax],al > 058F207E add byte ptr [eax],al > 058F2080 cmp edx,0FFFFFFFBh > 058F2083 jne 058F20B7 > 058F2089 mov ebx,dword ptr [eax] < Crash, access reading violation 0FFFFFFFBh This code is generated by virtualForThunkGenerator() #if USE(JSVALUE64) slowCase.append( jit.branchTest64( CCallHelpers::NonZero, GPRInfo::regT0, GPRInfo::tagMaskRegister)); #else slowCase.append( jit.branch32( CCallHelpers::NotEqual, GPRInfo::regT1, CCallHelpers::TrustedImm32(JSValue::CellTag))); #endif jit.loadPtr(CCallHelpers::Address(GPRInfo::regT0, JSCell::structureOffset()), GPRInfo::nonArgGPR2); slowCase.append( jit.branchPtr( CCallHelpers::NotEqual, CCallHelpers::Address(GPRInfo::nonArgGPR2, Structure::classInfoOffset()), CCallHelpers::TrustedImmPtr(JSFunction::info()))); The fix is to change nonArgGPR0 and nonArgGPR1 to be regT0 and regT1 respectively in linkClosureCall(). Patch in progress. Created attachment 217493 [details]
Patch
(In reply to comment #6) > Created an attachment (id=217493) [details] > Patch Tested this on Mac OS X 32 & 64 and ARMv7. Comment on attachment 217493 [details]
Patch
r=me
Committed r159593: <http://trac.webkit.org/changeset/159593> Why does the title of this bug say [Win] when it’s not a Windows-specific issue? (In reply to comment #11) > Why does the title of this bug say [Win] when it’s not a Windows-specific issue? When filed, I assumed it was Win-only. I'm not aware that it crashed on other platforms. The fix was cross-platform, though. OK. Next time, folks, lets retitle once we discover it’s not platform specific. |