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?)

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

+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

+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.

(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)

(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.

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.

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

(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.

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 on attachment 207819 [details] Partial fix Should we be using vm->getCTIStub(nativeCallGenerator) here instead, like the 64bit JIT does?

(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.

(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

(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")));

(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

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".

(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?

Another option is to pack into an int64. That's what we do for EncodedJSValue.

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]

(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."

(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 )

(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.

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.

(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.

(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.

(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 !

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.

(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.

(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.

Can confirm no crashes in JSC tests with the patch applied on the GTK port under a 32-bit chroot.

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.

(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}

(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)?

(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

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.

(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.

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.

Committed r153612: <http://trac.webkit.org/changeset/153612>

(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.

Created attachment 207983 [details] jsc test result on ARM

(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.

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