libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lassi Tuura
Subject: Re: [Libunwind-devel] Crash in libunwind 0.99 on x86_64
Date: Wed, 21 Apr 2010 00:54:54 +0200

Hi,

> How hard/easy is it to turn on validation to be always on?

See the "Always validate all addresses" patch I submitted a little while ago.

Regards,
Lassi

> 
> - Mark
> 
> 
> Lassi Tuura wrote:
>> 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
>> 
>> _______________________________________________
>> Libunwind-devel mailing list
>> 
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/libunwind-devel
>> 
>>   
>> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]