Re: JIT test crash

[Michael Goffioul]

On Wed, Aug 1, 2012 at 5:43 PM, Max Brister <address@hidden> wrote:

On Wed, Aug 1, 2012 at 11:40 AM, marco atzeri <address@hidden> wrote:
> On 8/1/2012 6:20 PM, Michael Goffioul wrote:
>>
>> I'm seeing a segfault on my MSVC-compiled version of octave (gui branch,
>> rev 6889217b9d78) when running the test suite in pt-jit.cc:
>>
>> octave.exe:2> test('../src/pt-jit.cc', 'verbose')
>>  >>>>>
>> C:\Software\MinGW\msys\1.0\home\goffioul\src\octave-hg-gui\src/pt-jit.cc
>>    ***** test
>>   inc = 1e-5;
>>   result = 0;
>>   for ii = 0:inc:1
>>     result = result + inc * (1/3 * ii * ii);
>>   endfor
>>   assert (abs (result - 1/9) < 1e-5);
>>    ***** test
>>   inc = 1e-5;
>>   result = 0;
>>   for ii = 0:inc:1
>>     # the ^ operator's result is complex
>>     result = result + inc * (1/3 * ii ^ 2);
>>   endfor
>>   assert (abs (result - 1/9) < 1e-5);
>> panic: Segmentation violation -- stopping myself...
>>
>> Max, any idea what could cause this?
>>
>> Michael.
>>
>
> on cygwin
> PASSES 10 out of 10 tests
> with  default branch  c53c28c7c811
>
> In theory the gui branch should have no influence on the jit
> but there are at least 3 additional changeset regarding jit in the
> default branch that you are missing

These changes should have any impact on this crash. I think this might
be an msvc vs gcc issue (or a 64 vs 32 bit issue).

Ok, this time it looks like an alignment problem. Maybe you're already aware of it, but MSVC aligns the stack on 4 bytes, while GCC aligns the stack on 16 bytes (and code generated by GCC assumes the incoming stack is also aligned on 16 bytes). I've attached the disassembled code for the following for-loop:

inc = 1e-5, result = 0

for ii = 0:inc:1, result = result + inc * (1/3 * ii ^ 2);, endfor

The crash occurs at the pshufd call (address 02D3010F), because at that point EBP is not aligned on 8 bytes (hence EBP-88h is not aligned on 16 bytes), its value is 0x0012F9EC. According to PSHUFD documentation, this generates a general protection fault. I could verify that by altering EBP value, I can avoid the crash. By carefully modifying ESP before calling the LLVM-compiled function, I could even make the for-loop succeed and get the expected result.

The bottom-line is: it looks like LLVM-JIT makes assumptions on the stack-alignment that are not always true (this is weird, as I compiled LLVM with MSVC, so it should somehow know how to generate compatible assembly code). Max, does that ring a bell to you? Is there any way to control the assumptions on the stack alignment (GCC has -mstackrealign and -mincoming-stack-boundary flags)?

Michael.

jit_crash.s
Description: Binary data