From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28728 invoked by alias); 21 Jun 2011 15:04:01 -0000 Received: (qmail 28703 invoked by uid 22791); 21 Jun 2011 15:04:00 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_GM X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jun 2011 15:03:48 +0000 From: "fawzi at gmx dot ch" To: gdb-prs@sourceware.org Subject: [Bug shlibs/11488] fsf gdb x86_64-apple-darwin crashes when loading libraries due to an endless loop X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: shlibs X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fawzi at gmx dot ch X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 21 Jun 2011 15:04:00 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2011-q2/txt/msg00460.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11488 --- Comment #11 from Fawzi Mohamed 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.