Dibyendu Majumdar
2015-Apr-25 20:19 UTC
[LLVMdev] Invalid or unaligned stack exception on Windows
Hi, I wrote sometime ago about this issue (see links below). http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084089.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084193.html At the time I thought the problem was due to a bug in my code, and that I had fixed it. But sadly it seems that the issue is still present - it just got hidden by whatever change I made. The error only occurs when a longjmp() call is invoked - but not at every longjmp() call - many longjmp() calls appear to be fine while one of them fails. Depending on compilation option (/O1 or /O2) the failure occurs at different places so I cannot spot an obvious pattern. The scenario is: C code calls setjmp() and eventually calls JITed code. JITed code calls a C function C function calls other C functions eventually leading to longjmp() call. Note that the longjmp call is not directly from JITed code. The error only occurs on Windows. I am using Visual Studio 2013 64-bit. However, it does not occur in a debug build (MSVC optimization mode /Od) - but occurs when I use /O1 or /O2. I do not get this error on MAC OSX Yosemite (using clang) or on Ubuntu (using gcc). On Ubuntu I am running gcc with -fsanitize=address to detect any memory issues. LLVM JIT optimization does not make a difference - i.e. the error occurs regardless of LLVM optimization settings. I am really at a loss as to how to find the root cause. How can I check whether there are stack alignment issues in JITed code? Can I enable address sanitizer in MCJIT so that any memory errors can be trapped? Should I build LLVM and my project using mingw-64 to see if same error occurs - is this supported on Windows? I would really appreciate any input on this issue. Thanks and Regards Dibyendu
Dibyendu Majumdar
2015-Apr-25 22:07 UTC
[LLVMdev] Invalid or unaligned stack exception on Windows
I have an example test program (smallest I could construct) that triggers the problem. The relevant line is commented in the code. https://github.com/dibyendumajumdar/ravi/tree/master/ravi-tests/longjmp_issue I have also dumped the IR for the three functions that are compiled. The C code that does the longjmp and setjmp is at: https://github.com/dibyendumajumdar/ravi/blob/master/src/ldo.c See functions luaD_throw() and luaD_rawrunprotected()
Reid Kleckner
2015-Apr-27 18:04 UTC
[LLVMdev] Invalid or unaligned stack exception on Windows
Are you using split stacks of some kind? Are you sure these actually work as intended on Win64? Based on the source code, it looks like you are allocating stack manually, but I could be wrong. What triple are you using with LLVM to generate code? There isn't much else information here, but you can try to zero in on the problem by checking the stack alignment manually with a helper like: void CheckAlignment() { assert((((uintptr_t)_AddressOfReturnAddress() + 8) & 15) == 0); } Run this near where LLVM calls back into C code. If it fails, disassemble the calling LLVM function and look at that to see if there's something wrong with the prologue. Sending that along with any followups would be helpful. On Sat, Apr 25, 2015 at 3:07 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> I have an example test program (smallest I could construct) that > triggers the problem. The relevant line is commented in the code. > > > https://github.com/dibyendumajumdar/ravi/tree/master/ravi-tests/longjmp_issue > > I have also dumped the IR for the three functions that are compiled. > > The C code that does the longjmp and setjmp is at: > > https://github.com/dibyendumajumdar/ravi/blob/master/src/ldo.c > > See functions luaD_throw() and luaD_rawrunprotected() > _______________________________________________ > 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/20150427/5da99b49/attachment.html>