Bug 119140

Summary: REGRESSION: Crash beneath cti_vm_throw_slowpath due to invalid CallFrame pointer
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Blocker CC: allan.jensen, barraclough, cgarcia, fpizlo, ggaren, hausmann, jbriance, loki, mark.lam, mhahnenberg, msaboff, oliver, ossy, rgabor, xinchao.peng, zan, zherczeg
Priority: P1    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 119440, 119441    
Bug Blocks: 119405, 119433    
Attachments:
Description Flags
Partial fix
none
Fix for X86 32-bit (release and debug builds). DO NOT COMMIT
none
Patch
fpizlo: review+
jsc test result on ARM none

Description Csaba Osztrogonác 2013-07-26 02:14:41 PDT
There are 27 jsc test (run-javascriptcore-tests) crashes
and more than 100 layout test crashes on 35 bit platforms,
for example Qt Linux 32 bit and Qt ARM buildbots:
- http://build.webkit.sed.hu/builders/x86-32%20Linux%20Qt%20Debug/builds/26627
- http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9112

I'll upload gdb backtraces soon.
Comment 1 Csaba Osztrogonác 2013-07-26 02:16:50 PDT
Here is a backtrace after running fast/js tests on 32 bit Qt Linux
in debug mode for fast/js/JSON-parse-reviver.html:

$ gdb WebKitBuild/Debug/bin/DumpRenderTree core
GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/webkitbuildbot/oszi/WebKit/WebKitBuild/Debug/bin/DumpRenderTree...done.
[New LWP 30365]
[New LWP 30374]
[New LWP 30398]
[New LWP 30397]
[New LWP 30402]
[New LWP 30401]
[New LWP 30400]
[New LWP 30399]
[New LWP 30404]
[New LWP 30403]

warning: Can't read pathname for load map: Input/output error.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/home/webkitbuildbot/oszi/WebKit/WebKitBuild/Debug/bin/DumpRenderTree -'.
Program terminated with signal 11, Segmentation fault.
#0  0xf38aa94f in ?? () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Gui.so.5
(gdb)
(gdb) bt
#0  0xf38aa94f in ?? () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Gui.so.5
#1  0xf38aaaee in ?? () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Gui.so.5
#2  0xf307ff61 in __run_exit_handlers (status=139, listp=0xf31ee3e4, run_list_atexit=true) at exit.c:78
#3  0xf307ffed in __GI_exit (status=139) at exit.c:100
#4  0xf5c38bca in dumpBacktraceSignalHandler (sig=11) at /home/webkitbuildbot/oszi/WebKit/Source/WTF/wtf/Assertions.cpp:352
#5  <signal handler called>
#6  0xf58c9412 in JSC::CodeBlock::vm() () at /home/webkitbuildbot/oszi/WebKit/Source/WTF/wtf/PrintStream.h:59
#7  0xf5ad7025 in cti_vm_throw_slowpath (callFrame=0xf5ace796) at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jit/JITStubs.cpp:2167
#8  0xf5ace79d in ctiVMThrowTrampolineSlowpath () at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/runtime/IndexingType.h:139
#9  0xf5ab0f56 in JSC::JITCode::execute (this=0x84e3bf8, stack=0x83bf57c, callFrame=0xeab00190, vm=0x83b6598)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jit/JITCode.cpp:46
#10 0xf5a9a5b9 in JSC::Interpreter::execute (this=0x83bf570, eval=0xed0ec3b0, callFrame=0xeab00138, thisValue=..., scope=0xec62ff78)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:1208
#11 0xf5a9566d in JSC::eval (callFrame=0xeab00138) at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:148
#12 0xf5aebccd in llint_slow_path_call_eval (exec=0xeab000b0, pc=0x84ed7c8)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1109
#13 0xf5af2357 in llint_op_call_eval () from /home/webkitbuildbot/oszi/WebKit/WebKitBuild/Debug/lib/libQt5WebKit.so.5
#14 0xeab000b0 in ?? ()
#15 0xf5ab0f56 in JSC::JITCode::execute (this=0x84956b0, stack=0x83bf57c, callFrame=0xeab00058, vm=0x83b6598)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jit/JITCode.cpp:46
#16 0xf5a98d28 in JSC::Interpreter::execute (this=0x83bf570, program=0xed0ecfb8, callFrame=0xeec5f78c, thisObj=0xeec9ffd8)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:856
#17 0xf5b756bc in JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) ()
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/runtime/Completion.cpp:83
#18 0xf45d5270 in WebCore::JSMainThreadExecState::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) ()
    at /usr/include/c++/4.6/bits/stl_algobase.h:195
#19 0xf45f2821 in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) ()
    at /usr/include/c++/4.6/bits/stl_algobase.h:195
#20 0xf45f291a in WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#21 0xf489d072 in WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#22 0xf4a30185 in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript&) () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#23 0xf4a2fffa in WebCore::HTMLScriptRunner::executeParsingBlockingScript() () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#24 0xf4a30491 in WebCore::HTMLScriptRunner::executeParsingBlockingScripts() () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#25 0xf4a305f4 in WebCore::HTMLScriptRunner::executeScriptsWaitingForLoad(WebCore::CachedResource*) () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#26 0xf4a225c1 in WebCore::HTMLDocumentParser::notifyFinished(WebCore::CachedResource*) () at /usr/include/c++/4.6/bits/stl_algobase.h:195
#27 0xf4b70bcb in WebCore::CachedResource::checkNotify (this=0x84a4e18)
    at /home/webkitbuildbot/oszi/WebKit/Source/WebCore/loader/cache/CachedResource.cpp:369
#28 0xf4b70cb3 in WebCore::CachedResource::finishLoading (this=0x84a4e18)
    at /home/webkitbuildbot/oszi/WebKit/Source/WebCore/loader/cache/CachedResource.cpp:385
#29 0xf4b78550 in WebCore::CachedScript::finishLoading(WebCore::ResourceBuffer*) ()
    at /home/webkitbuildbot/oszi/WebKit/Source/WebCore/platform/network/ResourceHandleClient.h:111
#30 0xf4bca208 in WebCore::SubresourceLoader::didFinishLoading (this=0x84a5238, finishTime=0)
    at /home/webkitbuildbot/oszi/WebKit/Source/WebCore/loader/SubresourceLoader.cpp:282
#31 0xf4bc161f in WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) ()
---Type <return> to continue, or q <return> to quit---
    at /home/webkitbuildbot/oszi/WebKit/Source/WebCore/platform/network/ResourceHandleClient.h:111
#32 0xf4ffda80 in WebCore::QNetworkReplyHandler::finish() () at /usr/include/c++/4.6/bits/stl_algobase.h:218
#33 0xf4ffc768 in WebCore::QNetworkReplyHandlerCallQueue::flush() () at /usr/include/c++/4.6/bits/stl_algobase.h:218
#34 0xf4ffc4b4 in WebCore::QNetworkReplyHandlerCallQueue::push(void (WebCore::QNetworkReplyHandler::*)()) () at /usr/include/c++/4.6/bits/stl_algobase.h:218
#35 0xf4ffd370 in WebCore::QNetworkReplyWrapper::didReceiveFinished() () at /usr/include/c++/4.6/bits/stl_algobase.h:218
#36 0xf4fffa62 in WebCore::QNetworkReplyWrapper::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
    at /usr/include/c++/4.6/bits/stl_algobase.h:218
#37 0xf35739ad in QMetaObject::activate(QObject*, int, int, void**) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#38 0xf35743cb in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#39 0xf3c61fd5 in QNetworkReply::finished() () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Network.so.5
#40 0xf3c62250 in ?? () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Network.so.5
#41 0xf3571b53 in QMetaCallEvent::placeMetaCall(QObject*) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#42 0xf3575062 in QObject::event(QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#43 0xf3da8e34 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Widgets.so.5
#44 0xf3dac844 in QApplication::notify(QObject*, QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Widgets.so.5
#45 0xf354aeee in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#46 0xf354d0b4 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#47 0xf354d60c in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#48 0xf35982c4 in ?? () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#49 0xf283ccda in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#50 0xf283d0e5 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#51 0xf283d1c1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#52 0xf35986d8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/local/Trolltech/Qt5/Qt-5.0.1/lib/libQt5Core.so.5
#53 0xf0962036 in ?? ()
#54 0x0835ef80 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Comment 2 Csaba Osztrogonác 2013-07-26 02:27:52 PDT
Here is a shorter gdb backtrace for a jsc test:

$ gdb --args ../../../../WebKitBuild/Debug/bin/jsc -s  -f ./js1_6/shell.js -f ./js1_6/Array/shell.js -f ./js1_6/Array/regress-304828.js
GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/webkitbuildbot/oszi/WebKit/WebKitBuild/Debug/bin/jsc...done.
(gdb) run
Starting program: /home/webkitbuildbot/oszi/WebKit/WebKitBuild/Debug/bin/jsc -s -f ./js1_6/shell.js -f ./js1_6/Array/shell.js -f ./js1_6/Array/regress-304828.js
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xf60d7b40 (LWP 11820)]
[New Thread 0xf56ffb40 (LWP 11821)]
[New Thread 0xf4efeb40 (LWP 11822)]
[New Thread 0xf44ffb40 (LWP 11823)]
[New Thread 0xf3affb40 (LWP 11824)]
[New Thread 0xf30ffb40 (LWP 11825)]
[New Thread 0xf26ffb40 (LWP 11826)]
BUGNUMBER: 304828

STATUS: Array Generic Methods


Program received signal SIGSEGV, Segmentation fault.
0x080c1a48 in JSC::CodeBlock::vm() () at /home/webkitbuildbot/oszi/WebKit/Source/WTF/wtf/PrintStream.h:59
59          }
(gdb) bt
#0  0x080c1a48 in JSC::CodeBlock::vm() () at /home/webkitbuildbot/oszi/WebKit/Source/WTF/wtf/PrintStream.h:59
#1  0x082e827d in cti_vm_throw_slowpath (callFrame=0x82df9ee) at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jit/JITStubs.cpp:2167
#2  0x082df9f5 in ctiVMThrowTrampolineSlowpath () at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/runtime/IndexingType.h:139
#3  0x082c2122 in JSC::JITCode::execute (this=0x89f69c0, stack=0x89deccc, callFrame=0xf1700058, vm=0x89d5828)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jit/JITCode.cpp:46
#4  0x082a896c in JSC::Interpreter::execute (this=0x89decc0, program=0xf153f9a8, callFrame=0xf16bfc8c, thisObj=0xf167fee8)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:856
#5  0x0838c864 in JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) ()
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/runtime/Completion.cpp:83
#6  0x0805657a in runWithScripts (globalObject=0xf16bfc38, scripts=0xffffd0d0, dump=134603264)
    at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jsc.cpp:596
#7  0x08057269 in jscmain (argc=8, argv=0xffffd1f4) at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jsc.cpp:812
#8  0x080563a3 in main (argc=8, argv=0xffffd1f4) at /home/webkitbuildbot/oszi/WebKit/Source/JavaScriptCore/jsc.cpp:554
Comment 3 Csaba Osztrogonác 2013-07-26 02:41:38 PDT
+info:
- tests crash with enabled LLINT, enabled baseline JIT and enabled DFG JIT
- tests crash with enabled LLINT, enabled baseline JIT and disabled DFG JIT
- tests _pass_ with enabled LLINT, disabled baseline JIT and disabled DFG JIT
Comment 4 Csaba Osztrogonác 2013-07-26 02:59:27 PDT
+info: there are same crashes on ARM traditional and ARM Thumb2 too:
- ARM traditional: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9112
- ARM Thumb2: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9113

It seems the bug is related to JSVALUE32_64 not to x86 or ARM architecture.
Comment 5 Oliver Hunt 2013-07-26 08:44:10 PDT
(In reply to comment #2)
> Here is a shorter gdb backtrace for a jsc test:
> 
Thanks!

This is really weird as it implies a bogus call frame, but somehow on on 32_64, and only on gcc (i'm assuming) builds.

Ossy: You're on ubuntu right?  I may try seeing if i can make this break in a VM (certainly convincing such a setup to work may prevent similar horrors to this in future)
Comment 6 Csaba Osztrogonác 2013-07-26 08:50:31 PDT
(In reply to comment #5)
> (In reply to comment #2)
> > Here is a shorter gdb backtrace for a jsc test:
> > 
> Thanks!
> 
> This is really weird as it implies a bogus call frame, but somehow on on 32_64, and only on gcc (i'm assuming) builds.
> 
> Ossy: You're on ubuntu right?  I may try seeing if i can make this break in a VM (certainly convincing such a setup to work may prevent similar horrors to this in future)

Yes, Qt bots run on Ubuntu 12.04. It's super easy to setup a QtWebKit build
environment on Ubuntu,just follow the "First steps before gardening" here:
http://trac.webkit.org/wiki/QtWebKitGardening

Meta packages install all dependency, build-qt5.sh build the necessary
Qt version from git. It doesn't take more than an hour.

Thanks for looking into this bug.
Comment 7 Csaba Osztrogonác 2013-07-30 15:38:12 PDT
I managed to build jsc of QtWebKit with clang on Ubuntu 12.04 
and got the same jsc test failures as with the GCC build.

Here is the clang version:
$ clang --version
Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix

Additionally we got the same failures on ARM on WebKitNix with GCC 4.7
(after the FTL changes merged to the nix repository)

So it seems this bug isn't related to GCC compiler or Qt port, but
the bug is somewhere in JSVALUE32_64 implementation inside JSC.
Comment 8 Carlos Garcia Campos 2013-07-30 23:38:09 PDT
Yes, I'm getting a lot of crashes too after the FTL merge with the GTK+ port in 32 bit platform, so this is not Qt specific at all
Comment 9 Zan Dobersek 2013-07-31 00:33:56 PDT
(In reply to comment #5)
> This is really weird as it implies a bogus call frame, but somehow on on 32_64, and only on gcc (i'm assuming) builds.

A bogus call frame is exactly what's happening.

In a breakpoint that's set on JSC::cti_vm_throw_slowpath, `info registers` in gdb shows that the actual and bogus callFrame parameter to the function is stored in the %edx register. If I modify the ctiVMThrowTrampolineSlowpath ASM to move the contents of the %edi register (which point to the correct JSC::CallFrame) into the %edx register, then breaking on JSC::cti_vm_throw_slowpath shows that the argument is now the correct one, and the function executes without a problem. The program crashes later in the JSC::jsCast assertion, due to these changes.

OTOH, breaking in JSC::cti_vm_throw_slowpath and manually setting callFrame to the correct pointer on every break makes the program work without problems. So yes, the problem is in the bogus call frame parameter of the JSC::cti_vm_throw_slowpath call.
Comment 10 Julien Brianceau 2013-07-31 01:45:25 PDT
Created attachment 207819 [details]
Partial fix

Seems to be better better with this patch, but issues are remaining.

Without this patch, run-fast-jsc gives me:
405 tests passed, 52 tests failed, 22 tests crashed.

With this patch, run-fast-jsc gives me:
422 tests passed, 35 tests failed, 3 tests crashed.
Comment 11 Geoffrey Garen 2013-07-31 08:09:25 PDT
Comment on attachment 207819 [details]
Partial fix

Should we be using vm->getCTIStub(nativeCallGenerator) here instead, like the 64bit JIT does?
Comment 12 Michael Saboff 2013-07-31 12:17:26 PDT
(In reply to comment #9)
> (In reply to comment #5)
> > This is really weird as it implies a bogus call frame, but somehow on on 32_64, and only on gcc (i'm assuming) builds.
> 
> A bogus call frame is exactly what's happening.
> 
> In a breakpoint that's set on JSC::cti_vm_throw_slowpath, `info registers` in gdb shows that the actual and bogus callFrame parameter to the function is stored in the %edx register. If I modify the ctiVMThrowTrampolineSlowpath ASM to move the contents of the %edi register (which point to the correct JSC::CallFrame) into the %edx register, then breaking on JSC::cti_vm_throw_slowpath shows that the argument is now the correct one, and the function executes without a problem. The program crashes later in the JSC::jsCast assertion, due to these changes.
> 
> OTOH, breaking in JSC::cti_vm_throw_slowpath and manually setting callFrame to the correct pointer on every break makes the program work without problems. So yes, the problem is in the bogus call frame parameter of the JSC::cti_vm_throw_slowpath call.

ctiVMThrowTrampolineSlowpath moves the callFrame register (%edi) into %ecx, which should be the first argument register for functions with the "fastcall" attribute.  The JIT_STUB macro before the definition of cti_vm_throw_slowpath() should be setting fast call.  %edx is the second "fast call" parameter.

Can you verify that JIT_STUB resolves to __attribute__ ((fast call)).  Also provide the disassembly of the fist 15 or so instructions of cti_vm_throw_slowpath() so we can see where it is expecting the argument.
Comment 13 Julien Brianceau 2013-07-31 12:33:18 PDT
(In reply to comment #11)
> (From update of attachment 207819 [details])
> Should we be using vm->getCTIStub(nativeCallGenerator) here instead, like the 64bit JIT does?
I've just tried and it doesn't solve the issue: not better, not worst. If I replace the whole function implementation by vm->getCTIStub(nativeCallGenerator), I still get "28 regressions found" with run-javascriptcore-tests and "405 tests passed, 52 tests failed, 22 tests crashed" with run-fast-jsc
Comment 14 Julien Brianceau 2013-07-31 12:47:15 PDT
(In reply to comment #12)
> 
> ctiVMThrowTrampolineSlowpath moves the callFrame register (%edi) into %ecx, which should be the first argument register for functions with the "fastcall" attribute.  The JIT_STUB macro before the definition of cti_vm_throw_slowpath() should be setting fast call.  %edx is the second "fast call" parameter.
> 
> Can you verify that JIT_STUB resolves to __attribute__ ((fast call)).  Also provide the disassembly of the fist 15 or so instructions of cti_vm_throw_slowpath() so we can see where it is expecting the argument.

When I compile JITStubs.cpp with -S, I get this:

.globl cti_vm_throw_slowpath
	.hidden	cti_vm_throw_slowpath
	.type	cti_vm_throw_slowpath, @function
cti_vm_throw_slowpath:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	subl	$60, %esp
	call	__i686.get_pc_thunk.bx
	addl	$_GLOBAL_OFFSET_TABLE_, %ebx
	movl	-8(%edx), %eax
	movl	52(%eax), %eax
	movl	%edx, 18684(%eax)
	movl	22340(%eax), %esi
	movl	22344(%eax), %edi
	movl	%esi, 12(%esp)
	movl	%edi, 16(%esp)
	movl	%edx, 8(%esp)
	movl	%eax, 4(%esp)
	movl	%ecx, (%esp)
	movl	%ecx, -28(%ebp)
	call	_ZN3JSC11jitThrowNewEPNS_2VMEPNS_9ExecStateENS_7JSValueE@PLT
	subl	$4, %esp
	movl	-28(%ebp), %ecx
	movl	%ecx, %eax
	leal	-12(%ebp), %esp
	popl	%ebx
	popl	%esi
	popl	%edi
	popl	%ebp
	ret


When I compile JITStubs.cpp with -E, I get this:

ExceptionHandler __attribute__ ((fastcall)) cti_vm_throw_slowpath(CallFrame*) __attribute__((used)) __attribute__((visibility("hidden")));
Comment 15 Zan Dobersek 2013-07-31 14:34:49 PDT
(In reply to comment #14)
> (In reply to comment #12)
> When I compile JITStubs.cpp with -E, I get this:
> 
> ExceptionHandler __attribute__ ((fastcall)) cti_vm_throw_slowpath(CallFrame*) __attribute__((used)) __attribute__((visibility("hidden")));

Same on x86 with GCC.

Here's assembly related to cti_vm_throw_slowpath. Thanks for looking into this!

	.globl ctiVMThrowTrampolineSlowpath
.hidden ctiVMThrowTrampolineSlowpath
ctiVMThrowTrampolineSlowpath:
movl %edi, %ecx
call cti_vm_throw_slowpath
jmp *%edx

...

	.globl	cti_vm_throw_slowpath
	.hidden	cti_vm_throw_slowpath
	.type	cti_vm_throw_slowpath, @function
cti_vm_throw_slowpath:
.LFB11958:
	.loc 113 2165 0
	.cfi_startproc
	pushl	%ebp
.LCFI2232:
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
.LCFI2233:
	.cfi_def_cfa_register 5
	pushl	%ebx
	subl	$68, %esp
	.cfi_offset 3, -12
	call	__x86.get_pc_thunk.bx
	addl	$_GLOBAL_OFFSET_TABLE_, %ebx
	movl	%ecx, -28(%ebp)
	movl	%edx, -32(%ebp)
.LBB485:
	.loc 113 2166 0
	movl	-32(%ebp), %eax
	movl	%eax, (%esp)
	call	_ZNK3JSC9ExecState9codeBlockEv@PLT
	movl	%eax, (%esp)
	call	_ZN3JSC9CodeBlock2vmEv@PLT
	movl	%eax, -12(%ebp)
	.loc 113 2167 0
	movl	-12(%ebp), %eax
	movl	-32(%ebp), %edx
	movl	%edx, 18788(%eax)
	.loc 113 2168 0
	movl	-28(%ebp), %ecx
	movl	-12(%ebp), %eax
	movl	22472(%eax), %edx
	movl	22468(%eax), %eax
	movl	%eax, 12(%esp)
	movl	%edx, 16(%esp)
	movl	-32(%ebp), %eax
	movl	%eax, 8(%esp)
	movl	-12(%ebp), %eax
	movl	%eax, 4(%esp)
	movl	%ecx, (%esp)
	call	_ZN3JSC11jitThrowNewEPNS_2VMEPNS_9ExecStateENS_7JSValueE@PLT
	subl	$4, %esp
.LBE485:
	.loc 113 2169 0
	movl	-28(%ebp), %eax
	movl	-4(%ebp), %ebx
	leave
.LCFI2234:
	.cfi_restore 5
	.cfi_restore 3
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE11958:
	.size	cti_vm_throw_slowpath, .-cti_vm_throw_slowpath
Comment 16 Geoffrey Garen 2013-07-31 15:35:31 PDT
Julien and I discovered the problem here:

ExceptionHandler __attribute__ ((fastcall)) cti_vm_throw_slowpath(CallFrame* callFrame);

On some compilers, returning a struct causes the compiler to allocate the first register as the "pointer to return value".
Comment 17 Michael Saboff 2013-07-31 15:42:35 PDT
(In reply to comment #16)
> Julien and I discovered the problem here:
> 
> ExceptionHandler __attribute__ ((fastcall)) cti_vm_throw_slowpath(CallFrame* callFrame);
> 
> On some compilers, returning a struct causes the compiler to allocate the first register as the "pointer to return value".

Makes sense.  I was looking at the disassembly that Julien posted and the use of %ecx was throwing me.  The first arg (callFrame) was in %edx.

That means that ctiVMThrowTrampolineSlowpath will need to be modified for those compilers to allocate the struct space on the stack and put the address in %ecx, put callFrame in %edx and then on return use the values in the stack instead of %eax:edx

Did you determine any predefined macros that say the compiler is doing this?
Comment 18 Geoffrey Garen 2013-07-31 16:06:30 PDT
Another option is to pack into an int64. That's what we do for EncodedJSValue.
Comment 19 Peng Xinchao 2013-08-01 01:31:09 PDT
I happened the same issue  at GTK , ARM ,32bit  And  Disable DFG_JIT and FTL_JIT. Merge the patch , i happened other crash .
backtrace :
  1   0x400d1608 libjavascriptcoregtk-3.0.so.0(_ZN3JSC9CodeBlock14bytecodeOffsetEPNS_9ExecStateENS_16ReturnAddressPtrE+0x28b) [0x400d1608]
2   0x401290e0 libjavascriptcoregtk-3.0.so.0(_ZN3JSC8jitThrowEPNS_2VMEPNS_9ExecStateENS_7JSValueENS_16ReturnAddressPtrE+0x1b) [0x401290e0]
3   0x40144d3c libjavascriptcoregtk-3.0.so.0(JITStubThunked_vm_throw+0x1f) [0x40144d3c]
Comment 20 Julien Brianceau 2013-08-01 01:34:57 PDT
(In reply to comment #17)
> That means that ctiVMThrowTrampolineSlowpath will need to be modified for those compilers to allocate the struct space on the stack and put the address in %ecx, put callFrame in %edx and then on return use the values in the stack instead of %eax:edx

Exactly. To confirm this, I've replaced the implementation of ctiVMThrowTrampolineSlowpath in Source/JavaScriptCore/jit/JITStubsX86.h like this:

asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampolineSlowpath) "\n"
HIDE_SYMBOL(ctiVMThrowTrampolineSlowpath) "\n"
SYMBOL_STRING(ctiVMThrowTrampolineSlowpath) ":" "\n"
    "movl %edi, %edx" "\n"
    "call " LOCAL_REFERENCE(cti_vm_throw_slowpath) "\n"
    // When cti_vm_throw_slowpath returns, eax has callFrame and edx has handler address
    "movl (%ecx), %eax" "\n"
    "movl 4(%ecx), %edx" "\n"
    "jmp *%edx" "\n"
);

Results are ok:
- run-fast-jsc reports "426 tests passed, 34 tests failed, 0 tests crashed."
- run-javascriptcore-tests reports "0 regressions found. 0 tests fixed. OK."
Comment 21 Simon Hausmann 2013-08-01 06:27:26 PDT
(In reply to comment #17)
> (In reply to comment #16)
> > Julien and I discovered the problem here:
> > 
> > ExceptionHandler __attribute__ ((fastcall)) cti_vm_throw_slowpath(CallFrame* callFrame);
> > 
> > On some compilers, returning a struct causes the compiler to allocate the first register as the "pointer to return value".
> 
> Makes sense.  I was looking at the disassembly that Julien posted and the use of %ecx was throwing me.  The first arg (callFrame) was in %edx.
> 
> That means that ctiVMThrowTrampolineSlowpath will need to be modified for those compilers to allocate the struct space on the stack and put the address in %ecx, put callFrame in %edx and then on return use the values in the stack instead of %eax:edx
> 
> Did you determine any predefined macros that say the compiler is doing this?

I believe that is the standard System V ABI on x86, which is implemented by Linux, Mac OS X (not that 32-bit matters here I suppose :) and other Unixy variants . See also "Functions Returning Structures or Unions" in http://sco.com/developers/devspecs/abi386-4.pdf

The invisible pointer-to-returned-structure argument that's normally on the stack indeed moves into the first register then.

On Windows on the other hand the structure in this case (which is 8 bytes) is returned in an eax:edx pair, if it fits
( http://msdn.microsoft.com/en-us/library/984x0h58.aspx )
Comment 22 Julien Brianceau 2013-08-01 08:19:49 PDT
(In reply to comment #20)
> Results are ok:
> - run-fast-jsc reports "426 tests passed, 34 tests failed, 0 tests crashed."
> - run-javascriptcore-tests reports "0 regressions found. 0 tests fixed. OK."

Please note that results are ok for release builds ONLY (thanks to Zan who finds that debug builds were still KO with this).


(In reply to comment #21)
> I believe that is the standard System V ABI on x86, which is implemented by Linux, Mac OS X (not that 32-bit matters here I suppose :) and other Unixy variants . See also "Functions Returning Structures or Unions" in http://sco.com/developers/devspecs/abi386-4.pdf
> 
> The invisible pointer-to-returned-structure argument that's normally on the stack indeed moves into the first register then.
> 
> On Windows on the other hand the structure in this case (which is 8 bytes) is returned in an eax:edx pair, if it fits
> ( http://msdn.microsoft.com/en-us/library/984x0h58.aspx )

Thanks a lot for the documentation :) So this is not a compiler issue.
Comment 23 Julien Brianceau 2013-08-01 08:27:21 PDT
Created attachment 207928 [details]
Fix for X86 32-bit (release and debug builds). DO NOT COMMIT

Do not commit this patch. It fixes X86 32-bit builds (release and debug), but will break all other architectures (X86_64, sh4, ARM etc ...): each architecture dependent function ctiVMThrowTrampolineSlowpath must be adapated with this patch.

JSC experts, do you think this kind of patch is a good way to fix the issue? If so, I'll make changes for the architectures I know (X86_64 and sh4) and submit a new patch.
Comment 24 Michael Saboff 2013-08-01 08:39:55 PDT
(In reply to comment #21)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > Julien and I discovered the problem here:
> > > 
> > > ExceptionHandler __attribute__ ((fastcall)) cti_vm_throw_slowpath(CallFrame* callFrame);
> > > 
> > > On some compilers, returning a struct causes the compiler to allocate the first register as the "pointer to return value".
> > 
> > Makes sense.  I was looking at the disassembly that Julien posted and the use of %ecx was throwing me.  The first arg (callFrame) was in %edx.
> > 
> > That means that ctiVMThrowTrampolineSlowpath will need to be modified for those compilers to allocate the struct space on the stack and put the address in %ecx, put callFrame in %edx and then on return use the values in the stack instead of %eax:edx
> > 
> > Did you determine any predefined macros that say the compiler is doing this?
> 
> I believe that is the standard System V ABI on x86, which is implemented by Linux, Mac OS X (not that 32-bit matters here I suppose :) and other Unixy variants . See also "Functions Returning Structures or Unions" in http://sco.com/developers/devspecs/abi386-4.pdf
> 
> The invisible pointer-to-returned-structure argument that's normally on the stack indeed moves into the first register then.
> 
> On Windows on the other hand the structure in this case (which is 8 bytes) is returned in an eax:edx pair, if it fits
> ( http://msdn.microsoft.com/en-us/library/984x0h58.aspx )

Clang on MacOSX also passes an 8 byte structure in eax:edx.  That is why this isn't an issue on 32 bit Mac builds.
Comment 25 Michael Saboff 2013-08-01 08:40:17 PDT
(In reply to comment #23)
> Created an attachment (id=207928) [details]
> Fix for X86 32-bit (release and debug builds). DO NOT COMMIT
> 
> Do not commit this patch. It fixes X86 32-bit builds (release and debug), but will break all other architectures (X86_64, sh4, ARM etc ...): each architecture dependent function ctiVMThrowTrampolineSlowpath must be adapated with this patch.
> 
> JSC experts, do you think this kind of patch is a good way to fix the issue? If so, I'll make changes for the architectures I know (X86_64 and sh4) and submit a new patch.

We do not want to commit the patch.  It uses whatever ecx contains without allocating memory, thus trashing whatever ecx points to.  This patch could be fixed to allocate that space on the stack.

The other approach is to return the two 32 bit values as one 64 bit value just like and encoded JSValue.  This is in keeping with the X86 32 bit ABI.  I plan on posting such a patch this morning.
Comment 26 Julien Brianceau 2013-08-01 09:18:42 PDT
(In reply to comment #25)
> 
> We do not want to commit the patch.  It uses whatever ecx contains without allocating memory, thus trashing whatever ecx points to.  This patch could be fixed to allocate that space on the stack.

ecx is used as it was before: the first argument containing callFrame through fastcall. Memory for struct is reserved on stack (subl $8) and put in edx, the second argument through fastcall.


> The other approach is to return the two 32 bit values as one 64 bit value just like and encoded JSValue.  This is in keeping with the X86 32 bit ABI.  I plan on posting such a patch this morning.

I'm fine with this approach, provided we fix this bug :) Thanks in advance for your patch !
Comment 27 Michael Saboff 2013-08-01 10:47:57 PDT
Created attachment 207937 [details]
Patch

I tested this with MacOSX 32 bit build by running JS tests and examining the disassembly to verify that edx:eax are used for return values.  I also compiled this for ARM and verified via disassembly that r1:r0 are used for the return value.

Maintainers of other platforms should verify this solves the issue for them as well before the patch is committed.
Comment 28 Csaba Osztrogonác 2013-08-01 10:53:48 PDT
(In reply to comment #27)
> Created an attachment (id=207937) [details]
> Patch
> 
> I tested this with MacOSX 32 bit build by running JS tests and examining the disassembly to verify that edx:eax are used for return values.  I also compiled this for ARM and verified via disassembly that r1:r0 are used for the return value.
> 
> Maintainers of other platforms should verify this solves the issue for them as well before the patch is committed.

Thanks for the fix, I'll check it on x86 and ARM soon with GCC.
Comment 29 Csaba Osztrogonác 2013-08-01 11:41:05 PDT
(In reply to comment #27)
> Created an attachment (id=207937) [details]
> Patch
> 
> I tested this with MacOSX 32 bit build by running JS tests and examining the disassembly to verify that edx:eax are used for return values.  I also compiled this for ARM and verified via disassembly that r1:r0 are used for the return value.
> 
> Maintainers of other platforms should verify this solves the issue for them as well before the patch is committed.

I tested it on x86/GCC/QtWebKit in release and debug mode too and
run-javascriptore-tests pass without any fail, and there are only
7 crashes on fast/js:
Regressions: Unexpected crashes (7)
  fast/js/create-lots-of-workers.html [ Crash ]
  fast/js/dfg-string-out-of-bounds-check-structure.html [ Crash ]
  fast/js/dfg-string-out-of-bounds-cse.html [ Crash ]
  fast/js/dfg-string-out-of-bounds-negative-check-structure.html [ Crash ]
  fast/js/dfg-string-out-of-bounds-negative-proto-value.html [ Crash ]
  fast/js/regress/string-get-by-val-out-of-bounds-insane.html [ Crash ]
  fast/js/regress/string-get-by-val-out-of-bounds.html [ Crash ]

But it seems, it is a different bug, I'm going to file a new bug report about it.
Comment 30 Zan Dobersek 2013-08-01 12:47:01 PDT
Can confirm no crashes in JSC tests with the patch applied on the GTK port under a 32-bit chroot.
Comment 31 Csaba Osztrogonác 2013-08-01 13:36:03 PDT
unfortunately ARM is still unhappy with this patch:
- ARM traditional: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9246
- ARM thumb2: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9247

I'll check a disassembly soon.
Comment 32 Csaba Osztrogonác 2013-08-01 13:41:00 PDT
(In reply to comment #31)
> unfortunately ARM is still unhappy with this patch:
> - ARM traditional: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9246
> - ARM thumb2: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9247
> 
> I'll check a disassembly soon.

Here is an ARM Thumb2 disassembly:
00179dc8 <cti_vm_throw_slowpath>:
  179dc8:       b570            push    {r4, r5, r6, lr}
  179dca:       4603            mov     r3, r0
  179dcc:       f850 1c08       ldr.w   r1, [r0, #-8]
  179dd0:       b084            sub     sp, #16
  179dd2:       ae02            add     r6, sp, #8
  179dd4:       4602            mov     r2, r0
  179dd6:       6b49            ldr     r1, [r1, #52]   ; 0x34
  179dd8:       4630            mov     r0, r6
  179dda:       f501 4592       add.w   r5, r1, #18688  ; 0x4900
  179dde:       f501 44b1       add.w   r4, r1, #22656  ; 0x5880
  179de2:       622b            str     r3, [r5, #32]
  179de4:       e9d4 450e       ldrd    r4, r5, [r4, #56]       ; 0x38
  179de8:       e9cd 4500       strd    r4, r5, [sp]
  179dec:       f7e6 ffb0       bl      160d50 <JSC::jitThrowNew(JSC::VM*, JSC::ExecState*, JSC::JSValue)>
  179df0:       e896 0003       ldmia.w r6, {r0, r1}
  179df4:       f7e6 ff5c       bl      160cb0 <JSC::encode(JSC::ExceptionHandler)>
  179df8:       b004            add     sp, #16
  179dfa:       bd70            pop     {r4, r5, r6, pc}
Comment 33 Michael Saboff 2013-08-01 13:48:10 PDT
(In reply to comment #32)
> (In reply to comment #31)
> > unfortunately ARM is still unhappy with this patch:
> > - ARM traditional: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9246
> > - ARM thumb2: http://build.webkit.sed.hu/builders/ARMv7%20Linux%20Qt5%20Release%20%28Test%29/builds/9247
> > 
> > I'll check a disassembly soon.
> 
> Here is an ARM Thumb2 disassembly:
> 00179dc8 <cti_vm_throw_slowpath>:
>   179dc8:       b570            push    {r4, r5, r6, lr}
>   179dca:       4603            mov     r3, r0
>   179dcc:       f850 1c08       ldr.w   r1, [r0, #-8]
>   179dd0:       b084            sub     sp, #16
>   179dd2:       ae02            add     r6, sp, #8
>   179dd4:       4602            mov     r2, r0
>   179dd6:       6b49            ldr     r1, [r1, #52]   ; 0x34
>   179dd8:       4630            mov     r0, r6
>   179dda:       f501 4592       add.w   r5, r1, #18688  ; 0x4900
>   179dde:       f501 44b1       add.w   r4, r1, #22656  ; 0x5880
>   179de2:       622b            str     r3, [r5, #32]
>   179de4:       e9d4 450e       ldrd    r4, r5, [r4, #56]       ; 0x38
>   179de8:       e9cd 4500       strd    r4, r5, [sp]
>   179dec:       f7e6 ffb0       bl      160d50 <JSC::jitThrowNew(JSC::VM*, JSC::ExecState*, JSC::JSValue)>
>   179df0:       e896 0003       ldmia.w r6, {r0, r1}
>   179df4:       f7e6 ff5c       bl      160cb0 <JSC::encode(JSC::ExceptionHandler)>
>   179df8:       b004            add     sp, #16
>   179dfa:       bd70            pop     {r4, r5, r6, pc}

What about a disassembly of JSC::encode(JSC::ExceptionHandler)?
Comment 34 Csaba Osztrogonác 2013-08-01 13:50:19 PDT
(In reply to comment #33)
> What about a disassembly of JSC::encode(JSC::ExceptionHandler)?

00160cb0 <JSC::encode(JSC::ExceptionHandler)>:
  160cb0:       b084            sub     sp, #16
  160cb2:       ab02            add     r3, sp, #8
  160cb4:       e883 0003       stmia.w r3, {r0, r1}
  160cb8:       e893 0003       ldmia.w r3, {r0, r1}
  160cbc:       e88d 0003       stmia.w sp, {r0, r1}
  160cc0:       b004            add     sp, #16
  160cc2:       4770            bx      lr
Comment 35 Michael Saboff 2013-08-01 14:13:45 PDT
Ossy, the disassembly you provided seems reasonable.  Below is what my ARM build produces. In both cases, the results of cgi_vm_throw_slowpath are left in r0:r1.

JavaScriptCore`cti_vm_throw_slowpath:
   0x35b318:  push   {r7, lr}
   0x35b31a:  mov    r7, sp
   0x35b31c:  sub    sp, #32
   0x35b31e:  str    r0, [sp, #28]
   0x35b320:  bl     0x19a310                  ; JSC::ExecState::codeBlock() const
   0x35b324:  bl     0x198a60                  ; JSC::CodeBlock::vm()
   0x35b328:  str    r0, [sp, #24]
   0x35b32a:  ldr    r1, [sp, #28]
   0x35b32c:  movw   r2, #18808
   0x35b330:  str    r1, [r0, r2]
   0x35b332:  ldr    r0, [sp, #24]
   0x35b334:  ldr    r2, [sp, #28]
   0x35b336:  movw   r1, #22496
   0x35b33a:  add    r1, r0
   0x35b33c:  vldr   d16, [r1]
   0x35b340:  vstr   d16, [sp, #8]
   0x35b344:  ldr    r3, [sp, #8]
   0x35b346:  ldr    r1, [sp, #12]
   0x35b348:  mov    r9, sp
   0x35b34a:  str.w  r1, [r9]
   0x35b34e:  add    r1, sp, #16
   0x35b350:  str    r0, [sp, #4]
   0x35b352:  mov    r0, r1
   0x35b354:  ldr    r1, [sp, #4]
   0x35b356:  bl     0x34324c                  ; JSC::jitThrowNew(JSC::VM*, JSC::ExecState*, JSC::JSValue)
   0x35b35a:  ldr    r0, [sp, #16]
   0x35b35c:  ldr    r1, [sp, #20]
   0x35b35e:  bl     0x3430bc                  ; JSC::encode(JSC::ExceptionHandler)
   0x35b362:  add    sp, #32
   0x35b364:  pop    {r7, pc}
   0x35b366:  nop    

JavaScriptCore`JSC::encode(JSC::ExceptionHandler):
   0x3430bc:  sub    sp, #16
   0x3430be:  str    r0, [sp, #8]
   0x3430c0:  str    r1, [sp, #12]
   0x3430c2:  vldr   d16, [sp, #8]
   0x3430c6:  vstr   d16, [sp]
   0x3430ca:  ldr    r0, [sp]
   0x3430cc:  ldr    r1, [sp, #4]
   0x3430ce:  add    sp, #16
   0x3430d0:  bx     lr

Please provide a stack trace for one of the failures and the disassembly of ctiVMThrowTrampolineSlowpath.
Comment 36 Julien Brianceau 2013-08-01 14:41:51 PDT
(In reply to comment #27)
> Created an attachment (id=207937) [details]
> Patch
> 
> Maintainers of other platforms should verify this solves the issue for them as well before the patch is committed.

Ok for me too on X86 32-bit. I'll check tomorrow it's ok for sh4 architecture.
Comment 37 Michael Saboff 2013-08-01 14:53:24 PDT
I'm going to check in the latest patch as it gets most ports working again.  I'll keep the bug open and can work with other port maintainers to get their ports working.
Comment 38 Michael Saboff 2013-08-01 14:56:34 PDT
Committed r153612: <http://trac.webkit.org/changeset/153612>
Comment 39 Csaba Osztrogonác 2013-08-01 23:00:06 PDT
(In reply to comment #35)
> Please provide a stack trace for one of the failures and the disassembly of ctiVMThrowTrampolineSlowpath.

Here is the disassembly:
00174628 <ctiVMThrowTrampolineSlowpath>:
  174628:       4628            mov     r0, r5
  17462a:       f005 fbcd       bl      179dc8 <cti_vm_throw_slowpath>
  17462e:       f8dd b05c       ldr.w   fp, [sp, #92]   ; 0x5c
  174632:       f8dd a058       ldr.w   sl, [sp, #88]   ; 0x58
  174636:       f8dd 9054       ldr.w   r9, [sp, #84]   ; 0x54
  17463a:       f8dd 8050       ldr.w   r8, [sp, #80]   ; 0x50
  17463e:       9f13            ldr     r7, [sp, #76]   ; 0x4c
  174640:       9e12            ldr     r6, [sp, #72]   ; 0x48
  174642:       9d11            ldr     r5, [sp, #68]   ; 0x44
  174644:       9c10            ldr     r4, [sp, #64]   ; 0x40
  174646:       f8dd e03c       ldr.w   lr, [sp, #60]   ; 0x3c
  17464a:       b01a            add     sp, #104        ; 0x68
  17464c:       4708            bx      r1
  17464e:       bf00            nop

Unfortunately crash backtrace seems a little bit strange:
(on DRT fast/js/JSON-parse-reviver.html)
Program received signal SIGSEGV, Segmentation fault.
0xaf49fc38 in ?? ()
(gdb) bt
#0  0xaf49fc38 in ?? ()
#1  0xaf49fc38 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

On run-javascriptcore-tests there isn't any crash, but simple fails,
I'll attach the actual.html, it might help.
Comment 40 Csaba Osztrogonác 2013-08-01 23:00:45 PDT
Created attachment 207983 [details]
jsc test result on ARM
Comment 41 Michael Saboff 2013-08-01 23:35:44 PDT
(In reply to comment #39)
> (In reply to comment #35)
> > Please provide a stack trace for one of the failures and the disassembly of ctiVMThrowTrampolineSlowpath.
> 
> Here is the disassembly:
> 00174628 <ctiVMThrowTrampolineSlowpath>:
>   174628:       4628            mov     r0, r5
>   17462a:       f005 fbcd       bl      179dc8 <cti_vm_throw_slowpath>
>   17462e:       f8dd b05c       ldr.w   fp, [sp, #92]   ; 0x5c
>   174632:       f8dd a058       ldr.w   sl, [sp, #88]   ; 0x58
>   174636:       f8dd 9054       ldr.w   r9, [sp, #84]   ; 0x54
>   17463a:       f8dd 8050       ldr.w   r8, [sp, #80]   ; 0x50
>   17463e:       9f13            ldr     r7, [sp, #76]   ; 0x4c
>   174640:       9e12            ldr     r6, [sp, #72]   ; 0x48
>   174642:       9d11            ldr     r5, [sp, #68]   ; 0x44
>   174644:       9c10            ldr     r4, [sp, #64]   ; 0x40
>   174646:       f8dd e03c       ldr.w   lr, [sp, #60]   ; 0x3c
>   17464a:       b01a            add     sp, #104        ; 0x68
>   17464c:       4708            bx      r1
>   17464e:       bf00            nop

I'm not sure we need to restore from the stack, but we certainly need to move r0 into the callFrameRegister, r5.  I'll have a patch to try in a few minutes.
Comment 42 Michael Saboff 2013-08-02 00:06:28 PDT
Ossy,

Try out the patch attached to the newly created bug https://bugs.webkit.org/show_bug.cgi?id=119433.