Currently the LLInt version of the throw handling (_llint_throw_from_slow_path_trampoline) and the JIT version (CCallHelpers::jumpToExceptionHandler()) put the contents of VM.callFrameForThrow in regT0. _llint_throw_from_slow_path_trampoline also sets the callFrame register to VM.topCallFrame. The callFrame register is overwritten in the catch handler to the value in regT0 or popped of the stack in the uncaught case. These exchanges should be simplified to have the catch handlers use VM.callFrameForThrow directly for setting callFrame register.
Created attachment 218562 [details] Patch
Comment on attachment 218562 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=218562&action=review r=me > Source/JavaScriptCore/jit/CCallHelpers.h:1578 > move(TrustedImmPtr(vm()), GPRInfo::regT0); > loadPtr(Address(GPRInfo::regT0, VM::targetMachinePCForThrowOffset()), GPRInfo::regT1); This should just be a load of an absolute address (VM::targetMachinePCForThrow). No need to put VM in a register.
Comment on attachment 218562 [details] Patch Attachment 218562 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/44958010
Comment on attachment 218562 [details] Patch Attachment 218562 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/45198001 New failing tests: js/dom/JSON-parse.html
Created attachment 218569 [details] Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-16 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Committed r160213: <http://trac.webkit.org/changeset/160213>
(In reply to comment #5) > Created an attachment (id=218569) [details] > Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2 > > The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. > Bot: webkit-ews-16 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5 Didn't see this crash before landing. Looks like the current callFrame in the catch block doesn't have a codeBlock. Investigating further.
Working in a fix.
(In reply to comment #8) > Working in a fix. Fix tracked with https://bugs.webkit.org/show_bug.cgi?id=125335 - REGRESSION(r160213): Crash in js/dom/JSON-parse.html