[Webkit-unassigned] [Bug 97586] [Qt] Fix crashes with LLInt C loop on 64 bit release mode

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=97586





--- Comment #14 from Mark Lam <mark.lam at apple.com>  2012-10-30 12:13:50 PST ---
(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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.