From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20801 invoked by alias); 17 Jul 2008 20:57:43 -0000 Received: (qmail 20792 invoked by uid 22791); 17 Jul 2008 20:57:43 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jul 2008 20:57:23 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 406FE98373 for ; Thu, 17 Jul 2008 20:57:22 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 21318982C3 for ; Thu, 17 Jul 2008 20:57:22 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KJaXR-0005FD-B4 for gdb-patches@sourceware.org; Thu, 17 Jul 2008 16:57:21 -0400 Date: Thu, 17 Jul 2008 20:57:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: [RFC] Detect loops in the solib chain Message-ID: <20080717205721.GA19882@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00347.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery 2008-07-17 Daniel Jacobowitz * solib-svr4.c (svr4_current_sos): Check for cycles in the list. Index: solib-svr4.c =================================================================== RCS file: /cvs/src/src/gdb/solib-svr4.c,v retrieving revision 1.87 diff -u -p -r1.87 solib-svr4.c --- solib-svr4.c 3 Jun 2008 12:59:37 -0000 1.87 +++ solib-svr4.c 17 Jul 2008 20:36:23 -0000 @@ -751,7 +751,8 @@ static struct so_list * svr4_current_sos (void) { CORE_ADDR lm; - struct so_list *head = 0; + int loop_flag = 0; + struct so_list *head = 0, *loop_so_list = NULL; struct so_list **link_ptr = &head; CORE_ADDR ldsomap = 0; @@ -825,6 +826,13 @@ svr4_current_sos (void) new->next = 0; *link_ptr = new; link_ptr = &new->next; + + /* Advance loop_so_list at half speed. */ + if (loop_so_list == NULL) + loop_so_list = new; + else if (loop_flag) + loop_so_list = loop_so_list->next; + loop_flag = !loop_flag; } } @@ -836,6 +844,13 @@ svr4_current_sos (void) lm = ldsomap = solib_svr4_r_ldsomap (); discard_cleanups (old_chain); + + /* Check for cycles in the list. */ + if (loop_so_list && loop_so_list->lm_info->lm_addr == lm) + { + warning (_("Corrupt shared library list")); + break; + } } if (head == NULL)