Bug 97586 - [Qt] Fix crashes with LLInt C loop on 64 bit release mode
Summary: [Qt] Fix crashes with LLInt C loop on 64 bit release mode
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Critical
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on: 100896 100899
Blocks: 79668 97584
  Show dependency treegraph
 
Reported: 2012-09-25 11:41 PDT by Csaba Osztrogonác
Modified: 2012-11-04 00:43 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Csaba Osztrogonác 2012-09-25 11:41:43 PDT
With LLInt C loop (ENABLE_JIT=0) there are 63 crashing JSC test
and 1000+ crashing layout tests on 64 bit in release mode.
There aren't crashis in debug mode and on 32 bit.
Comment 1 Csaba Osztrogonác 2012-09-25 11:42:54 PDT
crash log for LayoutTests/fast/js/JSON-parse.html:
---------------------------------------------------
$ gdb WebKitBuild/Release/bin/DumpRenderTree
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/oszi/WebKit/WebKitBuild/Release/bin/DumpRenderTree...done.
(gdb) run LayoutTests/fast/js/JSON-parse.html
Starting program: /home/oszi/WebKit/WebKitBuild/Release/bin/DumpRenderTree LayoutTests/fast/js/JSON-parse.html
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe7bad700 (LWP 22411)]
[New Thread 0x7fffa725d700 (LWP 22412)]
[Thread 0x7fffa725d700 (LWP 22412) exited]
[New Thread 0x7fffa725d700 (LWP 22413)]
[New Thread 0x7fffa6776700 (LWP 22414)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4d183ec in JSC::LLInt::CLoop::execute (callFrame=0x7fffa68310d8, bootstrapOpcodeId=<value optimized out>,
    isInitializationPass=<value optimized out>) at generated/LLIntAssembly.h:2385
2385        opcode = *CAST<Opcode*>(rBasePC.i8p + (rPC.i32 << 3) + intptr_t(0x0)); // /home/oszi/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:38
(gdb) bt
#0  0x00007ffff4d183ec in JSC::LLInt::CLoop::execute (callFrame=0x7fffa68310d8, bootstrapOpcodeId=<value optimized out>,
    isInitializationPass=<value optimized out>) at generated/LLIntAssembly.h:2385
#1  0x00007ffff4cfc711 in JSC::Interpreter::execute (this=<value optimized out>, program=<value optimized out>, callFrame=0x7fffa67ef388,
    thisObj=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:888
#2  0x00007ffff4da63dd in JSC::evaluate (exec=0x7fffa67ef388, source=..., thisValue=..., returnedException=0x7fffffffcfc0)
    at /home/oszi/WebKit/Source/JavaScriptCore/runtime/Completion.cpp:75
#3  0x00007ffff3c8bddb in WebCore::JSMainThreadExecState::evaluate (this=0x7fffe78d2878, sourceCode=..., world=<value optimized out>)
    at /home/oszi/WebKit/Source/WebCore/bindings/js/JSMainThreadExecState.h:77
#4  WebCore::ScriptController::evaluateInWorld (this=0x7fffe78d2878, sourceCode=..., world=<value optimized out>)
    at /home/oszi/WebKit/Source/WebCore/bindings/js/ScriptController.cpp:148
#5  0x00007ffff3c8c382 in WebCore::ScriptController::evaluate (this=0x7fffe78d2878, sourceCode=...)
    at /home/oszi/WebKit/Source/WebCore/bindings/js/ScriptController.cpp:165
#6  0x00007ffff3e93f97 in WebCore::ScriptElement::executeScript (this=0x7fffe78bd330, sourceCode=...)
    at /home/oszi/WebKit/Source/WebCore/dom/ScriptElement.cpp:301
#7  0x00007ffff4040392 in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent (this=0x7fffe78fe840, pendingScript=<value optimized out>)
    at /home/oszi/WebKit/Source/WebCore/html/parser/HTMLScriptRunner.cpp:139
#8  0x00007ffff40410d2 in WebCore::HTMLScriptRunner::executeParsingBlockingScript (this=0x7fffe78fe840)
    at /home/oszi/WebKit/Source/WebCore/html/parser/HTMLScriptRunner.cpp:118
#9  0x00007ffff4041508 in WebCore::HTMLScriptRunner::executeParsingBlockingScripts (this=0x7fffe78fe840)
    at /home/oszi/WebKit/Source/WebCore/html/parser/HTMLScriptRunner.cpp:190
#10 0x00007ffff40319c3 in WebCore::HTMLDocumentParser::notifyFinished (this=0x7fffe7904800, cachedResource=0x7fffa6831038)
    at /home/oszi/WebKit/Source/WebCore/html/parser/HTMLDocumentParser.cpp:514
#11 0x00007ffff4155a38 in WebCore::CachedResource::checkNotify (this=0x7fffe796b900) at /home/oszi/WebKit/Source/WebCore/loader/cache/CachedResource.cpp:247
#12 0x00007ffff41b5e62 in WebCore::SubresourceLoader::didFinishLoading (this=0x7fffe796d400, finishTime=<value optimized out>)
    at /home/oszi/WebKit/Source/WebCore/loader/SubresourceLoader.cpp:300
#13 0x00007ffff44f6282 in WebCore::QNetworkReplyHandler::finish (this=0x6be9d0)
    at /home/oszi/WebKit/Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:455
#14 0x00007ffff44f3199 in WebCore::QNetworkReplyHandlerCallQueue::flush (this=0x6bea08)
    at /home/oszi/WebKit/Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:196
#15 0x00007ffff44f3805 in WebCore::QNetworkReplyHandlerCallQueue::push (this=0x6bea08, method=0x7ffff44f60b0 <WebCore::QNetworkReplyHandler::finish()>)
    at /home/oszi/WebKit/Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:162
#16 0x00007ffff18f8058 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#17 0x00007ffff18f22ce in QObject::event(QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#18 0x00007ffff2ea40dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtWidgets.so.5
#19 0x00007ffff2eab957 in QApplication::notify(QObject*, QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtWidgets.so.5
#20 0x00007ffff18cd914 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#21 0x00007ffff18d2709 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#22 0x00007ffff1919a73 in ?? () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#23 0x00007ffff5b276f2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#24 0x00007ffff5b2b568 in ?? () from /lib/libglib-2.0.so.0
#25 0x00007ffff5b2b71c in g_main_context_iteration () from /lib/libglib-2.0.so.0
#26 0x00007ffff191954b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#27 0x00007ffff18cca7b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#28 0x00007ffff18d2d45 in QCoreApplication::exec() () from /usr/local/Trolltech/Qt5/Qt-5.0.0-beta1/lib/libQtCore.so.5
#29 0x0000000000428b2e in main (argc=2, argv=<value optimized out>) at /home/oszi/WebKit/Tools/DumpRenderTree/qt/DumpRenderTreeMain.cpp:195
(gdb)
Comment 2 Csaba Osztrogonác 2012-09-25 11:46:16 PDT
List of the failing JSC tests on 64 bit release mode:
------------------------------------------------------
** Danger, Will Robinson! Danger! The following failures have been introduced:
        ecma/Expressions/11.2.1-3-n.js
        ecma/Expressions/11.2.1-4-n.js
        ecma/Expressions/11.2.3-3-n.js
        ecma/Expressions/11.2.3-4-n.js
        ecma/LexicalConventions/7.2-2-n.js
        ecma/LexicalConventions/7.2-3-n.js
        ecma/LexicalConventions/7.2-4-n.js
        ecma/LexicalConventions/7.2-5-n.js
        ecma/LexicalConventions/7.5-10-n.js
        ecma/LexicalConventions/7.5-8-n.js
        ecma/Statements/12.6.3-6-n.js
        ecma/Statements/12.6.3-7-n.js
        ecma/Statements/12.6.3-8-n.js
        ecma/Statements/12.6.3-9-n.js
        ecma_2/Exceptions/boolean-002.js
        ecma_2/Exceptions/exception-004.js
        ecma_2/Exceptions/exception-005.js
        ecma_2/Exceptions/exception-006.js
        ecma_2/Exceptions/exception-007.js
        ecma_2/Exceptions/exception-010-n.js
        ecma_2/Exceptions/exception-011-n.js
        ecma_2/Exceptions/expression-002.js
        ecma_2/Exceptions/expression-003.js
        ecma_2/Exceptions/expression-004.js
        ecma_2/Exceptions/expression-016.js
        ecma_2/Exceptions/expression-017.js
        ecma_2/Exceptions/lexical-005.js
        ecma_2/Exceptions/lexical-007.js
        ecma_2/Exceptions/lexical-034.js
        ecma_2/Exceptions/statement-003.js
        ecma_2/Exceptions/statement-004.js
        ecma_2/Exceptions/statement-005.js
        ecma_2/Exceptions/statement-006.js
        ecma_2/Expressions/instanceof-003-n.js
        ecma_2/Expressions/instanceof-004-n.js
        ecma_2/Expressions/instanceof-005-n.js
        ecma_2/Statements/try-001.js
        ecma_2/Statements/try-003.js
        ecma_2/Statements/try-004.js
        ecma_2/Statements/try-005.js
        ecma_2/Statements/try-006.js
        ecma_2/Statements/try-007.js
        ecma_2/Statements/try-008.js
        ecma_2/Statements/try-009.js
        ecma_2/Statements/try-010.js
        ecma_2/Statements/try-012.js
        ecma_2/instanceof/instanceof-003.js
        ecma_3/Exceptions/15.11.4.4-1.js
        ecma_3/Exceptions/binding-001.js
        ecma_3/Exceptions/regress-181654.js
        ecma_3/Exceptions/regress-181914.js
        ecma_3/Exceptions/regress-58946.js
        ecma_3/Exceptions/regress-95101.js
        ecma_3/FunExpr/fe-001-n.js
        ecma_3/Function/regress-131964.js
        ecma_3/Function/regress-49286.js
        ecma_3/Object/8.6.2.6-001.js
        ecma_3/Operators/11.13.1-001.js
        js1_5/Exceptions/regress-121658.js
        js1_5/Regress/regress-146596.js
        js1_5/Regress/regress-89474.js
        js1_5/Regress/regress-96128-n.js
        js1_5/Scope/regress-192226.js

63 regressions found.
0 tests fixed.
Comment 3 Csaba Osztrogonác 2012-09-25 11:50:42 PDT
There is one failing test on 64 bit debug mode:

** Danger, Will Robinson! Danger! The following failures have been introduced:
        ecma_2/Exceptions/lexical-005.js

1 regression found.
0 tests fixed.
Comment 4 Csaba Osztrogonác 2012-10-25 12:24:21 PDT
The bug is still valid. Is there any plan to fix it?
Comment 5 Mark Lam 2012-10-25 13:35:17 PDT
(In reply to comment #4)
> The bug is still valid. Is there any plan to fix it?

This will have to be fixed by someone on the Qt side.  There are 0 failures due to the C++ llint when running on 64-bit mac.  The issue is likely due to something in the Qt port or its build configurations.
Comment 6 Laszlo Gombos 2012-10-25 21:58:30 PDT
(In reply to comment #3)
> There is one failing test on 64 bit debug mode:
> 
> ** Danger, Will Robinson! Danger! The following failures have been introduced:
>         ecma_2/Exceptions/lexical-005.js
> 
> 1 regression found.
> 0 tests fixed.

I think it would be helpful to know the test results for QtWebKit on Mac to understand if this difference is somehow related to the underlying OS or the build system.
Comment 7 Csaba Osztrogonác 2012-10-25 23:39:23 PDT
FYI: LLInt isn't buildable on Qt Mac - https://bugs.webkit.org/show_bug.cgi?id=97587 , so we can't check it.
Comment 8 Zoltan Herczeg 2012-10-30 07:50:56 PDT
I did some debugging. The bug is easy to reproduce. Just run an "array[0] = 32" expression in JS. Since "array" is undefined, an exception should be thrown. And that is what happens. The returnToThrow() in LLIntExceptions.cpp is executed. After the code is returned to (which is the slow case of resolve):

OFFLINE_ASM_LOCAL_LABEL(_offlineasm_noInstructions)

It crashes at:
   opcode = *CAST<Opcode*>(rBasePC.i8p + (rPC.i32 << 3) + intptr_t(0x0));

The address of the next instruction should go to t0, am I right?
LLInt::decodeResult(result, t0.instruction, t1.execState);

Is restoreStateAfterCCall() is this ok if you return with an exception?

What disturbs me the most: it uses rPC.i for all calculations, except the last one: rPC.i32 is used instead of i. Why?

Filip could you give me some ideas?
Comment 9 Zoltan Herczeg 2012-10-30 08:05:20 PDT
I replaced all rPC.i32 to rPC.i manually in LLIntAssembly.h and all jscore tests are passing now...
Comment 10 Mark Lam 2012-10-30 10:19:48 PDT
(In reply to comment #8)
> I did some debugging. The bug is easy to reproduce. Just run an "array[0] = 32" expression in JS. Since "array" is undefined, an exception should be thrown. And that is what happens. The returnToThrow() in LLIntExceptions.cpp is executed. After the code is returned to (which is the slow case of resolve):
> 
> OFFLINE_ASM_LOCAL_LABEL(_offlineasm_noInstructions)
> 
> It crashes at:
>    opcode = *CAST<Opcode*>(rBasePC.i8p + (rPC.i32 << 3) + intptr_t(0x0));
> 
> The address of the next instruction should go to t0, am I right?
> LLInt::decodeResult(result, t0.instruction, t1.execState);
> 
> Is restoreStateAfterCCall() is this ok if you return with an exception?
> 
> What disturbs me the most: it uses rPC.i for all calculations, except the last one: rPC.i32 is used instead of i. Why?

This is because in x86_64 mode, the PC is the bytecode offset, and not an address.  No piece of bytecode should be so big that it exceeds the 2G range of a 32 bit int.

(In reply to comment #9)
> I replaced all rPC.i32 to rPC.i manually in LLIntAssembly.h and all jscore tests are passing now...

In contrast, on mac x86_64, if I change the rPC.i32 to rPC.i, the tests will crash.

I wonder if this is a C++ compiler problem.  Try this test:
1. Modify llint/LowLevelInterpreter.cpp as follows:

=== BEGIN diff ===
     // rPC is an alias for vPC. Set up the alias:
     CLoopRegister& rPC = *CAST<CLoopRegister*>(&vPC);
 
+    printf(" &rPC.i32 = %p\n", &rPC.i32);
+    printf(" &rPC.i   = %p\n", &rPC.i);
+    rPC.i = 0xfedcba9876543211;
+    printf(" Setting rPC.i = 0xfedcba9876543211;\n");
+    printf(" raw rPC  = %p\n", *(void**)&rPC);
+    rPC.i32 = 0x00000000;
+    printf(" Setting rPC.i32 = 0x00000000;\n");
+    printf(" raw rPC  = %p\n", *(void**)&rPC);
+
 #if USE(JSVALUE32_64)
     vPC = codeBlock->instructions().begin();
 #else // USE(JSVALUE64)
=== END diff ===

2. Build jsc.
3. Create the following test.js file:

=== BEGIN ===
function foo() {
    array[0] = 32;
}

try {
   foo();
} catch (e) {
   print("caught: " + e);
}
=== END ===

4. Run jsc on the test file:

$ jsc test.js 

Here's the result I'm getting on mac x86_64:
=== BEGIN ===
$ jsc test.js 
 &rPC.i32 = 0x7fff519913b0
 &rPC.i   = 0x7fff519913b0
 Setting rPC.i = 0xfedcba9876543211;
 raw rPC  = 0xfedcba9876543211
 Setting rPC.i32 = 0x00000000;
 raw rPC  = 0xfedcba9800000000
caught: ReferenceError: Can't find variable: array
$
=== END ===

Let me know what results you are seeing on Qt.
Comment 11 Csaba Osztrogonác 2012-10-30 10:36:26 PDT
Thanks for the debugging guys.

Here is the output what Mark asked:
------------------------------------
 &rPC.i32 = 0x7fff1bfaa478
 &rPC.i   = 0x7fff1bfaa478
 Setting rPC.i = 0xfedcba9876543211;
 raw rPC  = 0xfedcba9876543211
 Setting rPC.i32 = 0x00000000;
 raw rPC  = 0xfedcba9800000000
Segmentation fault


and the output after s/rPC.i32/rPC.i/g:
----------------------------------------
 &rPC.i32 = 0x7fff01be4b58
 &rPC.i   = 0x7fff01be4b58
 Setting rPC.i = 0xfedcba9876543211;
 raw rPC  = 0xfedcba9876543211
 Setting rPC.i32 = 0x00000000;
 raw rPC  = 0xfedcba9800000000
caught: ReferenceError: Can't find variable: array
Comment 12 Mark Lam 2012-10-30 10:51:41 PDT
(In reply to comment #11)
> Thanks for the debugging guys.
> 
> Here is the output what Mark asked:
> ------------------------------------
>  &rPC.i32 = 0x7fff1bfaa478
>  &rPC.i   = 0x7fff1bfaa478
>  Setting rPC.i = 0xfedcba9876543211;
>  raw rPC  = 0xfedcba9876543211
>  Setting rPC.i32 = 0x00000000;
>  raw rPC  = 0xfedcba9800000000
> Segmentation fault
> 
> 
> and the output after s/rPC.i32/rPC.i/g:
> ----------------------------------------
>  &rPC.i32 = 0x7fff01be4b58
>  &rPC.i   = 0x7fff01be4b58
>  Setting rPC.i = 0xfedcba9876543211;
>  raw rPC  = 0xfedcba9876543211
>  Setting rPC.i32 = 0x00000000;
>  raw rPC  = 0xfedcba9800000000
> caught: ReferenceError: Can't find variable: array

That rules out any C++ compiler issue.  At this point, I'd suggest you guys do some debugging (since I can't reproduce the issue on my side) and audit the values of rBasePC and rPC on your port, and see where things went wrong.  As I said earlier, rPC is a bytecode offset (i.e. should be a small integer), and rBasePC should be a pointer to the start of the bytecode.

Since, you're working with the C++ llint, you can easily add this auditing (i.e. printfs or whatever) as follows: in the llint asm files, you can use the cloopDo debug llint instruction.  See the comment for cloopDo in offline/instructions.rb for details.  Here's an example of using it:

    cloopDo // printf(" TRACE rPC = %p\n", *(void**)&rPC);

The text you put after the // comment will be copied verbatim into the generated LLIntAssembly.h file.  Hence, you can use this mechanism to insert probes for your debugging.  The above example will add a printf to print the value of the rPC.

Good bug hunting.
Comment 13 Zoltan Herczeg 2012-10-30 11:34:04 PDT
I can only do debugging tomorrow, but I can tell you that that the issue is really the i32 thing. After the exception, t0.instruction is set to a low address  (0x22b4030), probably it points something to the data section, and the difference is much bigger than 2G. The strange thing is, why it crashes on your side with i?

SlowPathReturnType result = llint_slow_path_resolve(exec, pc);
LLInt::decodeResult(result, t0.instruction, t1.execState);

This result is returned by:

return LLInt::exceptionInstructions();

Just out of curiosity:

OFFLINE_ASM_LOCAL_LABEL(_offlineasm_noInstructions)

+       printf("catchRoutine %p\n", LLInt::exceptionInstructions());
        ExecState* exec = CAST<ExecState*>(cfr.vp);
        Instruction* pc = CAST<Instruction*>(rPC.vp);
        SlowPathReturnType result = llint_slow_path_resolve(exec, pc);
        LLInt::decodeResult(result, t0.instruction, t1.execState);
+       printf("t0.instruction: %p\n", t0.instruction);

catchRoutine 0x2004030
t0.instruction: 0x2004030

So it is set long before the exception occures, and it is a low address (outside the 2G range). What is happening on your machine?
Comment 14 Mark Lam 2012-10-30 12:13:50 PDT
(In reply to comment #13)
> I can only do debugging tomorrow, but I can tell you that that the issue is really the i32 thing. After the exception, t0.instruction is set to a low address  (0x22b4030), probably it points something to the data section, and the difference is much bigger than 2G. The strange thing is, why it crashes on your side with i?
> 
> SlowPathReturnType result = llint_slow_path_resolve(exec, pc);
> LLInt::decodeResult(result, t0.instruction, t1.execState);
> 
> This result is returned by:
> 
> return LLInt::exceptionInstructions();
> 
> Just out of curiosity:
> 
> OFFLINE_ASM_LOCAL_LABEL(_offlineasm_noInstructions)
> 
> +       printf("catchRoutine %p\n", LLInt::exceptionInstructions());
>         ExecState* exec = CAST<ExecState*>(cfr.vp);
>         Instruction* pc = CAST<Instruction*>(rPC.vp);
>         SlowPathReturnType result = llint_slow_path_resolve(exec, pc);
>         LLInt::decodeResult(result, t0.instruction, t1.execState);
> +       printf("t0.instruction: %p\n", t0.instruction);
> 
> catchRoutine 0x2004030
> t0.instruction: 0x2004030
> 
> So it is set long before the exception occures, and it is a low address (outside the 2G range). What is happening on your machine?

In the llint C++ helper function, the PC is a 64-bit pointer.  But in the llint interpreter, rPC is supposed to contain a small offset from rBasePC.  I had assumed that your snippet of code for _offlineasm_noInstructions above is an excerpt and not the complete code.  But now I suspect that it is not just an excerpt.  For your reference, here's is what the complete piece of generated LLIntAssembly.h for _offlineasm_noInstructions should look like:

=== BEGIN ===
  OFFLINE_ASM_LOCAL_LABEL(_offlineasm_noInstructions)
    rPC.i8p = rBasePC.i8p + (rPC.i << 3);                    // JavaScriptCore/llint/LowLevelInterpreter64.asm:81
    t3.i = rBasePC.i;                                        // JavaScriptCore/llint/LowLevelInterpreter64.asm:82
    {                                                        // JavaScriptCore/llint/LowLevelInterpreter64.asm:59
        ExecState* exec = CAST<ExecState*>(cfr.vp);
        Instruction* pc = CAST<Instruction*>(rPC.vp);
        SlowPathReturnType result = llint_slow_path_resolve(exec, pc);
        LLInt::decodeResult(result, t0.instruction, t1.execState);
    }
    rPC.i = t0.i;                                            // JavaScriptCore/llint/LowLevelInterpreter64.asm:86
    cfr.i = t1.i;                                            // JavaScriptCore/llint/LowLevelInterpreter64.asm:87
    rBasePC.i = t3.i;                                        // JavaScriptCore/llint/LowLevelInterpreter64.asm:88
    rPC.i = rPC.i - rBasePC.i;                               // JavaScriptCore/llint/LowLevelInterpreter64.asm:89
    rPC.u = rPC.u >> (intptr_t(0x3) & 0x1f);                 // JavaScriptCore/llint/LowLevelInterpreter64.asm:90
    rPC.i = rPC.i + intptr_t(0x5);                           // JavaScriptCore/llint/LowLevelInterpreter64.asm:37
    opcode = *CAST<Opcode*>(rBasePC.i8p + (rPC.i32 << 3) + intptr_t(0x0)); // JavaScriptCore/llint/LowLevelInterpreter64.asm:38
    DISPATCH_OPCODE();
=== END ===

Does your code for _offlineasm_noInstructions look like this?

Note that the rPC is converted from an offset into a pointer before calling the slow path.  After the slow path, it is converted from a pointer back into an offset.  Your port should be doing the same thing.  Please verify if it is doing this.  Thanks.
Comment 15 Zoltan Herczeg 2012-10-30 12:51:17 PDT
Exactly it looks like that. I just didn't wanted to pollute the bugzilla. So LLInt::exceptionInstructions() contains something (an absolute byte code address perhaps) before the function enters the slow path, and the slow path returns with it. When the conversion happens, this address becomes a relative address, but this relative address is bigger than 2G. The question here, is that address is correct, or not. It seems correct, since all tests passed. But why it has low address? Perhaps that byte code array is allocated a different way?
Comment 16 Mark Lam 2012-10-31 00:51:47 PDT
(In reply to comment #9)
> I replaced all rPC.i32 to rPC.i manually in LLIntAssembly.h and all jscore tests are passing now...

Zoltan, you may be right about this.  I think there is a compounding effect of several bugs that were masking each other on my system.  I need to do some research tomorrow and will get back to you on this issue.
Comment 17 Zoltan Herczeg 2012-10-31 05:20:10 PDT
The initalization of exceptionInstructions is here:

LLIntData.cpp:
Data::s_exceptionInstructions = new Instruction[maxOpcodeLength + 1];

Later all opcodes are set to llint_throw_from_slow_path_trampoline in LowLevelInterpreter.cpp.

Probably you have different allocator, which allocates memory in the high region. The trick here is all opcodes up to maxOpcodeLength set to the same poiner, which effectively ignores the opcode length of _offlineasm_noInstructions.
Comment 18 Zoltan Herczeg 2012-10-31 06:28:40 PDT
I changed rthe following:

--- a/Source/JavaScriptCore/offlineasm/cloop.rb
+++ b/Source/JavaScriptCore/offlineasm/cloop.rb
@@ -252,7 +252,7 @@ class BaseIndex
             offsetValue = "(#{index.clValue(:int32)} << #{scaleShift}) + #{offset.clValue})"
             "(ASSERT(#{offsetValue} == offsetof(JITStackFrame, globalData)), &sp->globalData)"
         else
-            "#{base.clValue(:int8Ptr)} + (#{index.clValue(:int32)} << #{scaleShift}) + #{offset.clValue}"
+            "#{base.clValue(:int8Ptr)} + (#{index.clValue(:int)} << #{scaleShift}) + #{offset.clValue}"
         end
     end
     def int8MemRef

But there are crashes.

macro loadConstantOrVariable(index, value) :

OFFLINE_ASM_LOCAL_LABEL(_offlineasm_64_loadConstantOrVariable__done)
[...]
t1.i32 = t1.i32 - *CAST<int32_t*>(t2.i8p + 24);
[...]
t1.i = *CAST<int32_t*>(t3.i8p + (t1.i << 2) + intptr_t(0x0));

This is obviously crashes.

Would it be possible to change only this one?

# Utilities.
macro dispatch(advance)
    addp advance, PC
    jmp [PB, PC, 8]
end
Comment 19 Mark Lam 2012-10-31 16:09:16 PDT
The C++ llint BaseIndex codegen is incorrect.  Zoltan identified the problem.  The fix is at https://bugs.webkit.org/show_bug.cgi?id=100899.  I chose to create a separate bug for the fix so that this once can continue tracking remaining Qt crashes if any.
Comment 20 Mark Lam 2012-10-31 16:20:52 PDT
(In reply to comment #19)
> The C++ llint BaseIndex codegen is incorrect.  Zoltan identified the problem.  The fix is at https://bugs.webkit.org/show_bug.cgi?id=100899.  I chose to create a separate bug for the fix so that this once can continue tracking remaining Qt crashes if any.

Just got more details from Filip about the semantics of x86_64 instructions.  The above fix is invalid.  Will update the above bug, and post the real fix when ready.
Comment 21 Mark Lam 2012-11-01 00:35:31 PDT
(In reply to comment #20)
> Just got more details from Filip about the semantics of x86_64 instructions.  The above fix is invalid.  Will update the above bug, and post the real fix when ready.

The fix for the issue Zoltan identified has been landed in r133131: <http://trac.webkit.org/changeset/133131> for https://bugs.webkit.org/show_bug.cgi?id=100899.

Please check if there are any more crashes after this fix.  Thanks.
Comment 22 Csaba Osztrogonác 2012-11-02 02:34:38 PDT
JSC tests pass now, I'll run layout tests immediately.
Comment 23 Simon Hausmann 2012-11-02 02:45:35 PDT
(In reply to comment #21)
> (In reply to comment #20)
> > Just got more details from Filip about the semantics of x86_64 instructions.  The above fix is invalid.  Will update the above bug, and post the real fix when ready.
> 
> The fix for the issue Zoltan identified has been landed in r133131: <http://trac.webkit.org/changeset/133131> for https://bugs.webkit.org/show_bug.cgi?id=100899.
> 
> Please check if there are any more crashes after this fix.  Thanks.

Thanks Mark, Zoltan and Ossy! :)
Comment 24 Csaba Osztrogonác 2012-11-04 00:43:11 PDT
(In reply to comment #22)
> JSC tests pass now, I'll run layout tests immediately.

Tests pass now, we can close this bug. But there are still 2 failing
test / notifyDone timeout related to LLINT C loop - https://bugs.webkit.org/show_bug.cgi?id=101159