Re: [Libunwind-devel] Crash in libunwind 0.99 on x86_64

[Lassi Tuura]

Hi,

>> Thanks Arun. I suspect the git version would fix the crash I saw, if
>> it occurred at the exact same address in the first page again, however
>> I wanted to understand the likelihood of getting a crash at some other
>> place in the future.
> 
> The likelihood depends on the compiler version used, presence of handwritten 
> asm, third party libraries without proper unwind information etc.
> 
> There are better solutions possible  (eg: implementing interfaces to query 
> valid stack addresses in the threading library you're using), but they 
> require modifications to other pieces of low level code (eg: libc).

We found that when interrupted by signals - such as sampling performance 
profiler - it's essential to turn the validation always on. Otherwise sooner or 
later the application will crash in libunwind accessing bad memory address.

By far the biggest reason for this is inaccurate unwind information for 
function epilogues - the exit paths from the function don't have any unwind 
info, causing endless havoc if you happen to sample the stack there. There have 
been a number of recent updates to GCC on this, but I am not sure if they all 
made it even to 4.5.0 which was released just a few days ago. Anything before 
4.5.0 is certainly prone to have significant issues of this sort.

GDB will also fail to produce a useful stack trace in comparable circumstances. 
The fix needs to come from the compiler.

Similar caveats of course apply to debug info produced by other means. One 
version of GLIBC I looked at has incorrect (manually entered) unwind info for 
at least one function.

Regards,
Lassi