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
Anton Korobeynikov
2015-Jun-30 10:17 UTC
[LLVMdev] Crashes on Windows 8 with >4k stack frames
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-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Nicholas Chapman
2015-Jun-30 10:58 UTC
[LLVMdev] Crashes on Windows 8 with >4k stack frames
It's a known issue. I believe it's fixed in trunk however.
What LLVM version are you using?
Nick
On 30/06/2015 10:21, Ephrim Khong 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
We tested on 3.4.2 and 3.5.1. Later versions are slightly problematic to test since they don't compile with VS2010. Do you happen to know if it's fixed in one of the released versions, or if there is a workaround (chkstk?) or a bug report online? Thanks! Eph On 30.06.2015 12:58, Nicholas Chapman wrote:> It's a known issue. I believe it's fixed in trunk however. > What LLVM version are you using? > > Nick > > On 30/06/2015 10:21, Ephrim Khong 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 >
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 > > >