thr3ads.net - llvm dev - [LLVMdev] Crash in libunwind [May 2011]

If this information is useful, please help other people find it:
Share via:

Christophe de Dinechin

2011-May-30 09:45 UTC

[LLVMdev] Crash in libunwind

Hello,


We have been investigating a crash in our application that may be related to how
stack frames are generated by the JIT. We observe it with LLVM 2.9, but not with
LLVM 2.8, everything else being the same. The crash occurs when dynamically
generated code calls code that tries to unwind the stack.

Here is what the stack trace looks like on MacOSX 10.6 :

0   libSystem.B.dylib                 0x00007fff87297bdb
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::parseCIE(libunwind::LocalAddressSpace&,
unsigned long long,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 75
1   libSystem.B.dylib                 0x00007fff87298795
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE(libunwind::LocalAddressSpace&,
unsigned long long,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::FDE_Info*,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 149
2   libSystem.B.dylib                 0x00007fff8719d928
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::setInfoBasedOnIPRegister(bool) + 312
3   libSystem.B.dylib                 0x00007fff8719e348
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::step() + 216
4   libobjc.A.dylib                   0x00007fff8852c4b6
objc_addExceptionHandler + 828
5   com.apple.CoreFoundation          0x00007fff82399722 _CFDoExceptionOperation
+ 402
6   com.apple.AppKit                  0x00007fff887e9989 _NSAppKitLock + 79


The parts above that vary from crash to crash, but we usually have some
window-management stuff and some of our code, with some dynamically-generated
code higher in the stack. Our application can run reliably for hours, and runs
correctly in Valgrind AFAWK, as long as we avoid the cases where dynamically
generated code invokes window management functions.

We have tried with both NoFramePointerElim set and cleared, it doesn't seem
to make a difference.

Has anybody else run into a similar stack trace? I have not found much through
Google, but there's a MacRuby ticket with a very similar stack trace :
http://www.macruby.org/trac/ticket/427. This was closed as
"worksforme", but the original poster indicated it was still failing
for him, although only on one particular machine. This suggests the problem may
depend on the specific version of LLVM just like it does for us.

Can anybody suggest ideas on how to investigate this further? Any
instrumentation in LLVM or libUnwind worth activating?


Thanks
Christophe

Garrison Venn

2011-May-30 15:30 UTC

head link

[LLVMdev] Crash in libunwind

This may be bogus, but do you have: 

llvm::JITExceptionHandling = true;

for the code that generates the dynamic code? 

It has been a while, but I don't recall what will happen when dynamic code,
generated
with jit exception handling turned off, invokes libraries which in turn try to
unwind the stack
via the libunwind api. However given that you say the code works with 2.8, my
concern maybe
irrelevant. Personally I have a feeling that with llvm::JITExceptionHandling
turned off, the
unwinding should correctly "pass through" the generated code. With
llvm::JITExceptionHandling turned
on, a potential crash could occur if the personality function associated with
the generated code
is not behaving properly. 

Hopefully others will respond to rectify my thoughts and therefore help you out.
:-) I'm guessing
more data will be needed though.

Garrison


On May 30, 2011, at 5:45, Christophe de Dinechin wrote:
> Hello,
> 
> 
> We have been investigating a crash in our application that may be related
to how stack frames are generated by the JIT. We observe it with LLVM 2.9, but
not with LLVM 2.8, everything else being the same. The crash occurs when
dynamically generated code calls code that tries to unwind the stack.
> 
> Here is what the stack trace looks like on MacOSX 10.6 :
> 
> 0   libSystem.B.dylib                 0x00007fff87297bdb
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::parseCIE(libunwind::LocalAddressSpace&,
unsigned long long,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 75
> 1   libSystem.B.dylib                 0x00007fff87298795
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE(libunwind::LocalAddressSpace&,
unsigned long long,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::FDE_Info*,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 149
> 2   libSystem.B.dylib                 0x00007fff8719d928
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::setInfoBasedOnIPRegister(bool) + 312
> 3   libSystem.B.dylib                 0x00007fff8719e348
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::step() + 216
> 4   libobjc.A.dylib                   0x00007fff8852c4b6
objc_addExceptionHandler + 828
> 5   com.apple.CoreFoundation          0x00007fff82399722
_CFDoExceptionOperation + 402
> 6   com.apple.AppKit                  0x00007fff887e9989 _NSAppKitLock + 79
> 
> 
> The parts above that vary from crash to crash, but we usually have some
window-management stuff and some of our code, with some dynamically-generated
code higher in the stack. Our application can run reliably for hours, and runs
correctly in Valgrind AFAWK, as long as we avoid the cases where dynamically
generated code invokes window management functions.
> 
> We have tried with both NoFramePointerElim set and cleared, it doesn't
seem to make a difference.
> 
> Has anybody else run into a similar stack trace? I have not found much
through Google, but there's a MacRuby ticket with a very similar stack trace
: http://www.macruby.org/trac/ticket/427. This was closed as
"worksforme", but the original poster indicated it was still failing
for him, although only on one particular machine. This suggests the problem may
depend on the specific version of LLVM just like it does for us.
> 
> Can anybody suggest ideas on how to investigate this further? Any
instrumentation in LLVM or libUnwind worth activating?
> 
> 
> Thanks
> Christophe
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Christophe de Dinechin

2011-Jun-01 07:57 UTC

head link

[LLVMdev] Crash in libunwind

Garison,


Thanks. Yes, we have JITExceptionHandling set. Specificaly :

    JITExceptionHandling = true;
    JITEmitDebugInfo = true;
    UnwindTablesMandatory = true;
    NoFramePointerElim = true;

Also, I was a bit hasty in saying that it works in 2.8. Apparently, it is
happening much less frequently.

Interestingly, the problem seems to go away with JITExceptionHandling = false.
We need to confirm that the problem is eliminated and not just displaced.


Christophe

On 30 mai 2011, at 17:30, Garrison Venn wrote:
> This may be bogus, but do you have: 
> 
> llvm::JITExceptionHandling = true;
> 
> for the code that generates the dynamic code? 
> 
> It has been a while, but I don't recall what will happen when dynamic
code, generated
> with jit exception handling turned off, invokes libraries which in turn try
to unwind the stack
> via the libunwind api. However given that you say the code works with 2.8,
my concern maybe
> irrelevant. Personally I have a feeling that with
llvm::JITExceptionHandling turned off, the
> unwinding should correctly "pass through" the generated code.
With llvm::JITExceptionHandling turned
> on, a potential crash could occur if the personality function associated
with the generated code
> is not behaving properly. 
> 
> Hopefully others will respond to rectify my thoughts and therefore help you
out. :-) I'm guessing
> more data will be needed though.
> 
> Garrison
> 
> 
> On May 30, 2011, at 5:45, Christophe de Dinechin wrote:
> 
>> Hello,
>> 
>> 
>> We have been investigating a crash in our application that may be
related to how stack frames are generated by the JIT. We observe it with LLVM
2.9, but not with LLVM 2.8, everything else being the same. The crash occurs
when dynamically generated code calls code that tries to unwind the stack.
>> 
>> Here is what the stack trace looks like on MacOSX 10.6 :
>> 
>> 0   libSystem.B.dylib                 0x00007fff87297bdb
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::parseCIE(libunwind::LocalAddressSpace&,
unsigned long long,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 75
>> 1   libSystem.B.dylib                 0x00007fff87298795
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE(libunwind::LocalAddressSpace&,
unsigned long long,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::FDE_Info*,
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 149
>> 2   libSystem.B.dylib                 0x00007fff8719d928
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::setInfoBasedOnIPRegister(bool) + 312
>> 3   libSystem.B.dylib                 0x00007fff8719e348
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::step() + 216
>> 4   libobjc.A.dylib                   0x00007fff8852c4b6
objc_addExceptionHandler + 828
>> 5   com.apple.CoreFoundation          0x00007fff82399722
_CFDoExceptionOperation + 402
>> 6   com.apple.AppKit                  0x00007fff887e9989 _NSAppKitLock
+ 79
>> 
>> 
>> The parts above that vary from crash to crash, but we usually have some
window-management stuff and some of our code, with some dynamically-generated
code higher in the stack. Our application can run reliably for hours, and runs
correctly in Valgrind AFAWK, as long as we avoid the cases where dynamically
generated code invokes window management functions.
>> 
>> We have tried with both NoFramePointerElim set and cleared, it
doesn't seem to make a difference.
>> 
>> Has anybody else run into a similar stack trace? I have not found much
through Google, but there's a MacRuby ticket with a very similar stack trace
: http://www.macruby.org/trac/ticket/427. This was closed as
"worksforme", but the original poster indicated it was still failing
for him, although only on one particular machine. This suggests the problem may
depend on the specific version of LLVM just like it does for us.
>> 
>> Can anybody suggest ideas on how to investigate this further? Any
instrumentation in LLVM or libUnwind worth activating?
>> 
>> 
>> Thanks
>> Christophe
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Maybe Matching Threads

Search for more apparently analagous threads

llvm dev - May 2011 - [LLVMdev] Crash in libunwind

[LLVMdev] Crash in libunwind

[LLVMdev] Crash in libunwind

[LLVMdev] Crash in libunwind

Maybe Matching Threads