[LLVMdev] Crashes on Windows 8 with >4k stack frames

[Yaron Keren]

With an old version of LLVM, this discussion and related patch may be
relevant.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131021/192392.html


2015-06-30 14:39 GMT+03:00 Ephrim Khong <dr.khong at gmail.com>:

> Thanks, chkstk was a very good pointer of what might go wrong!  I assume
> LLVM optimizes the chain of alloca/store to a single alloca & memset. With
> stack growing down, memset working upwards, memset would touch a byte after
> the guarding page.  Note sure if that assumption is correct, but it would
> explain what we see.
>
> Not sure yet if chkstk is emitted, will try to find out.
>
> Thanks,
> Eph
>
>
> On 30.06.2015 12:17, Anton Korobeynikov wrote:
>
>> Make sure the stack probes are emitted (__alloca / chkstk) and that
>> they indeed do probe the memory.
>>
>> On Tue, Jun 30, 2015 at 12:21 PM, Ephrim Khong <dr.khong at gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> we have an issue with our LLVM-based JIT compiler - executing the
>>> compiled
>>> code corrupts memory (and subsequently crashes) if we alloca more than
>>> 4k of
>>> variables (more than 511 8-byte ints). The same code works on Windows 7
>>> (32
>>> and 64 bit), Linux, MacOS. We compile LLVM and our program with
>>> Microsoft's
>>> Visual Studio 2010. Both debug and release builds are affected.
>>>
>>> The variables are created en-block at the beginning of the function with
>>> code looking like
>>>
>>> for (i=0; i<513; ++i) {
>>>    AllocaInst *variable =
>>>         mBuilder.CreateAlloca(Type::getInt64Ty(mContext),0,"");
>>>    mBuilder.CreateStore(GetConstI("INT4_8",0),variable);
>>> }
>>>
>>> We have not yet looked at the compiled machine code (same on Win 7 and
>>> 8, or
>>> differs?). But the 4k limit made us suspicious, as there were some bug
>>> reports - some still open - regarding this limit with LLVM [1,2].
>>>
>>> So the question is - before digging into this for more days - is there
>>> some
>>> known issue with this, or does anyone have an idea what might go wrong?
>>>
>>> Thanks,
>>> Eph
>>>
>>> [1] https://llvm.org/bugs/show_bug.cgi?id=2921
>>> [2] https://llvm.org/bugs/show_bug.cgi?id=8919
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/0d43524d/attachment.html>