[LLVMdev] Crash in libunwind

[Christophe de Dinechin]

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