[Bug shlibs/11488] fsf gdb x86_64-apple-darwin crashes when loadinglibraries due to an endless loop

["fawzi at gmx dot ch" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=11488

--- Comment #11 from Fawzi Mohamed <fawzi at gmx dot ch> 2011-06-21 15:03:12 UTC ---
I have found the problem, and a way to detect it.
decode_frame_entry and decode_frame_entry_1 decodes both CIE or FDE.
A FDE has a back pointer to its CIE.
Sometime on mac this pointer is broken and points back to a FDE.
In libobjc.A.dylib this is particularly broken, and points back to 
As to parse the CIE if the pointer is unknown one simply calls
decode_frame_enty this inconsistency is not detected. One should split the
function, so that one that decodes only CIE is used, or peek, and ensure that
the CIE pointer actually points to a CIE.

I think that there is a strong argument to introduce such a check, as it is
just the correct thing to do, and if done correctly it doesn't slow down the
parsing of .eh_frame section.

Then one should think what to do in such a case, one can set the cie to null
(something that is detected later on), or to the last CIE.

That is not the end of the problem, because I noted that the information that
gdb is parsing as .eh_frame is different from what
  otool -s __TEXT __eh_frame libobjc.A.dylib
outputs, I don't know if this is expected or not, but the __TEXT __eh_frame
section of the mach-o executable looks much more sensible. This might be
connected with fat binaries, but I haven't investigated it yet.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.