libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] Testing time


From: Lassi Tuura
Subject: Re: [Libunwind-devel] Testing time
Date: Tue, 29 Mar 2011 15:03:28 +0200

Hi,

> I went ahead and applied a bunch of patches yesterday. I believe it
> covers most of the things that were discussed on the list recently. I
> still haven't had a chance to review Lassi's performance fixes patch.
> Both 32 and 64 bit x86 are looking good (the same 4 known failures).
> 
> Please pull, test and let me know if I broke your platform.

I have some reports of crashes on RHEL6 + GCC 4.6 + gold linker. LTO may be 
involved, I am not sure.

There are sporadic failures in strange places like the code for parsing DWARF 
CIEs: dwarf_readu32 < parse_cie < _ULx86_64_dwarf_extract_proc_info_from_fde < 
_ULx86_64_dwarf_search_unwind_table < _ULx86_64_dwarf_find_proc_info < 
fetch_proc_info.

One crash was triggered in GCC's own unwinder when throwing an exception: 
read_encoded_value_with_base < _Unwind_IteratePhdrCallback < dl_iterate_phdr < 
_Unwind_Find_FDE < uw_frame_state_for < _Unwind_RaiseException < __cxa_throw. 
No libunwind code present in the process when this happened. It's possible both 
stumbled over the same issue.

So far this looks like potentially new forms of wrong unwind info showing up, 
or perhaps GCC 4.6 using (new?) DWARF info libunwind doesn't understand. If 
it's the latter it seems GCC itself doesn't understand its own unwind info then.

At the moment we don't even know what's triggering these - the tool chain we 
used was, ahem, a bit experimental. I'll report here if/when we can identify 
the actual source.

Regards,
Lassi


reply via email to

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