[Top][All Lists]
[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
>>
>>
>>