llvm dev - Apr 2015 - [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>

Hi there,

I had similar problem around LLVM 3.5 and I'm almost certain that is only
Windows 64-bit related. In my case longjmp was crashing from time to time
and moreover debugger trap was triggered inside longjmp every time (it
could be ignored). I haven't found a proper solution and switched from
library longjmp to builtin one (llvm.eh.sjlj.longjmp). Moving longjmp call
from C++ managed by MSVC to LLVM IR can also be helpful.

My guess is that longjmp does not work on Windows 64bit because it needs
correct stack unwinding information and LLVM does not deliver it. Back then
in 3.5 days exception handling on Windows was quite poor.

- Paweł

On Mon, Apr 27, 2015 at 8:08 PM Reid Kleckner <rnk at google.com> wrote:
> 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
>>
>
> _______________________________________________
> 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/c5c24f93/attachment.html>

On 27 April 2015 at 23:01, Paweł Bylica <chfast at gmail.com>
wrote:
> I had similar problem around LLVM 3.5 and I'm almost certain that is
only
> Windows 64-bit related. In my case longjmp was crashing from time to time
> and moreover debugger trap was triggered inside longjmp every time (it
could
> be ignored). I haven't found a proper solution and switched from
library
> longjmp to builtin one (llvm.eh.sjlj.longjmp). Moving longjmp call from C++
> managed by MSVC to LLVM IR can also be helpful.
>
> My guess is that longjmp does not work on Windows 64bit because it needs
> correct stack unwinding information and LLVM does not deliver it. Back then
> in 3.5 days exception handling on Windows was quite poor.
>
Hi,
Thank you - that's very helpful to know. If I compiled using gcc or
clang would this still be the case? Presumably I can still compile
LLVM using MSVC.

Regards
Dibyendu

On 27 April 2015 at 19:04, Reid Kleckner <rnk at google.com>
wrote:
> 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.
Hi,
Lua uses its own stack (which is just an array of value objects), and
Lua functions basically manipulate this data structure.
>
> What triple are you using with LLVM to generate code?
x86_64-pc-windows-msvc-elf
>
> 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.
>
Thank you - I will try this, although Pawel's reply on this issue
seems like a plausible explanation.
I am trying to figure out how to dump the disassembly from the
compiled code - it seems not so easy as dumping IR.
I will also try compiling the using clang or gcc to see if that makes
the problem go away.

Thanks and Regards
Dibyendu

I think Paweł identified the problem. The frames on the stack between the
setjmp and longjmp must have valid unwind information, which is described
here:
https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396

In particular, it has this line about JITed code:
  "For dynamically generated functions [JIT compilers], the runtime to
support these functions must either use RtlInstallFunctionTableCallback or
RtlAddFunctionTable to provide this information to the operating system.
Failure to do so will result in unreliable exception handling and debugging
of processes."

LLVM does not contain any references to these functions, so I must conclude
that unwinding through LLVM JITed frames on Win64 is not supported. Sorry.
:-(

You can try implementing your own setjmp / longjmp pair that bypasses the
libc versions. That might work.

On Mon, Apr 27, 2015 at 4:23 PM, Dibyendu Majumdar <mobile at
majumdar.org.uk>
wrote:
> On 27 April 2015 at 19:04, Reid Kleckner <rnk at google.com> wrote:
> > 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.
>
> Hi,
> Lua uses its own stack (which is just an array of value objects), and
> Lua functions basically manipulate this data structure.
>
> >
> > What triple are you using with LLVM to generate code?
>
> x86_64-pc-windows-msvc-elf
>
> >
> > 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.
> >
>
> Thank you - I will try this, although Pawel's reply on this issue
> seems like a plausible explanation.
> I am trying to figure out how to dump the disassembly from the
> compiled code - it seems not so easy as dumping IR.
> I will also try compiling the using clang or gcc to see if that makes
> the problem go away.
>
> Thanks and Regards
> Dibyendu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150427/6249972b/attachment.html>