From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6005 invoked by alias); 17 Jul 2008 21:07:25 -0000 Received: (qmail 5804 invoked by uid 22791); 17 Jul 2008 21:07:25 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jul 2008 21:07:07 +0000 Received: (qmail 18687 invoked from network); 17 Jul 2008 21:07:06 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Jul 2008 21:07:06 -0000 Message-ID: <487FB46E.40608@codesourcery.com> Date: Thu, 17 Jul 2008 21:07:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFC] Detect loops in the solib chain References: <20080717205721.GA19882@caradoc.them.org> In-Reply-To: <20080717205721.GA19882@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00348.txt.bz2 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. > > The best I could think of was to detect cycles. It's a linked list > that we're walking, so without cycles we're bounded by the amount of > memory in the debuggee; it's by no means foolproof, but this should > prevent more cases of wandering off into the woods than we do now. > > Does this look OK? Tested on x86_64-linux, no regressions. > What, no test case? :-) Anyway, it looks OK to me. (You could make a little script to scribble on the executable...) Stan