From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13022 invoked by alias); 17 Jul 2008 21:15:49 -0000 Received: (qmail 13009 invoked by uid 22791); 17 Jul 2008 21:15:48 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jul 2008 21:15:23 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id C23ED17F517 for ; Thu, 17 Jul 2008 18:02:20 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6HLFPSG2547996 for ; Thu, 17 Jul 2008 18:15:25 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6HLFKot030896 for ; Thu, 17 Jul 2008 18:15:20 -0300 Received: from [9.18.238.102] ([9.18.238.102]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6HLFKqH029998; Thu, 17 Jul 2008 18:15:20 -0300 Subject: Re: [RFC] Detect loops in the solib chain From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org In-Reply-To: <20080717205721.GA19882@caradoc.them.org> References: <20080717205721.GA19882@caradoc.them.org> Content-Type: text/plain Date: Thu, 17 Jul 2008 21:15:00 -0000 Message-Id: <1216329299.12209.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 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/msg00349.txt.bz2 On Thu, 2008-07-17 at 16:57 -0400, Daniel Jacobowitz wrote: > A MontaVista customer had a very interestingly corrupt core file - > there was a stray pointer in the list of loaded shared libraries. But > it pointed to something which looked enough like a shared library > entry to get by, and the bad entry's l_next pointed back at the > corrupted entry that led to it. So around and around we went, adding > the same two libraries to the list. When the solib chain reached > about 2GB, GDB was killed. For my own education: it looks to me that this customer won the lottery two times here (one for pointing to a link map fake entry, and the other for it to be circular). How often can this happen in practice? Can we expect somone else to have this problem in this millenium? :-) -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center