From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11813 invoked by alias); 18 Jul 2008 23:02:49 -0000 Received: (qmail 11658 invoked by uid 22791); 18 Jul 2008 23:02:40 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 23:02:21 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6IN2JSA006076 for ; Fri, 18 Jul 2008 19:02:19 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6IN2Ifw030677 for ; Fri, 18 Jul 2008 19:02:18 -0400 Received: from mesquite.lan (vpn-13-120.rdu.redhat.com [10.11.13.120]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6IN2Ia2010248 for ; Fri, 18 Jul 2008 19:02:18 -0400 Date: Fri, 18 Jul 2008 23:02:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFC] Detect loops in the solib chain Message-ID: <20080718160210.66b480e9@mesquite.lan> In-Reply-To: <20080717220959.GA10652@caradoc.them.org> References: <20080717205721.GA19882@caradoc.them.org> <8ac60eac0807171417h37cbe7d4x860d528d80358c8e@mail.gmail.com> <20080717214039.GA21465@caradoc.them.org> <8ac60eac0807171457g4f2c972es883f7210c7843a87@mail.gmail.com> <20080717220959.GA10652@caradoc.them.org> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00371.txt.bz2 On Thu, 17 Jul 2008 18:09:59 -0400 Daniel Jacobowitz wrote: > On Thu, Jul 17, 2008 at 02:57:03PM -0700, Paul Pluzhnikov wrote: > > On Thu, Jul 17, 2008 at 2:40 PM, Daniel Jacobowitz wrote: > > > > > @@ -784,14 +792,21 @@ svr4_current_sos (void) > > > > > > read_memory (lm, new->lm_info->lm, lmo->link_map_size); > > > > > > - lm = LM_NEXT (new); > > > + next_lm = LM_NEXT (new); > > > + > > > + if (prev_lm != 0 && LM_PREV (new) != prev_lm && ldsomap == 0) > > > > I think you want just: > > > > + if (LM_PREV (new) != prev_lm) > > > > First entry on the list should also be properly terminated, and > > ldsomap has nothing to do with whether the list is corrupt or not. > > You're right about prev_lm, thanks. The ldsomap check is necessary, > because that entry may not be on the list (see down below). As written, I agree that the ldsomap check is necessary. Of course, having this check means that as soon as ldsomap gets set, this integrity check is effectively disabled. I think that this will only matter if the ldsomap entry ends up having a non-zero LM_NEXT. It seems to me that the ldsomap check could be avoided if you were to set prev_lm to 0 just after ldsomap gets set. (It's been a while since I've checked, but I'm guessing that in the case of a unattached dynamic linker entry, you'd expect both LM_NEXT and LM_PREV for that entry to be zero.) Kevin