From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28898 invoked by alias); 31 Aug 2011 20:01:47 -0000 Received: (qmail 28879 invoked by uid 22791); 31 Aug 2011 20:01:43 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Aug 2011 20:01:28 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QyqyP-0003Ys-Ao for gdb-patches@sources.redhat.com; Wed, 31 Aug 2011 22:01:21 +0200 Received: from 209.226.137.108 ([209.226.137.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2011 22:01:21 +0200 Received: from aristovski by 209.226.137.108 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2011 22:01:21 +0200 To: gdb-patches@sources.redhat.com From: Aleksandar Ristovski Subject: dangling pointer in so_list Date: Wed, 31 Aug 2011 20:01:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020403060807000001080202" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 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: 2011-08/txt/msg00677.txt.bz2 This is a multi-part message in MIME format. --------------020403060807000001080202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1336 Hello, I run into a gdb crash examining a core file. This happened on gdb 7.3, on QNX. Unfortunately, I could not come up with a reproducible testcase on gnu/linux due to differences in dynamic linkers, but offer a detailed explanation instead: What happened is that a process loaded the same shared object more than once. Then it crashed and a core was generated. In the core, we had a link map specifying the same shared object more than once. While traversing the link map, gdb loaded shared objects (symbols), thus associating each so_list object with an objfile object. During the process, it detected duplicates and associated multiple so_list objects with the same objfile instance. At this point, a change to solib-search-path causes gdb to reload symbols, and the crash happens: while traversing so_list in solib.c:reload_shared_libraries_1, in one iteration gdb calls 'free_objfile' with a pointer to an instance of the objfile. In a subsequent iteration, it tries to do the same with, now, dangling pointer to the same objfile object. Not good. The attached patch fixes the issue. Thanks, Aleksandar Ristovski QNX Software Systems ChangeLog: Aleksandar Ristovski * solib.c (reload_shared_libraries_1): Check whether objfile is used before freeing it. --------------020403060807000001080202 Content-Type: text/x-patch; name="dangling_objfile_in_so_list-201108311551.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dangling_objfile_in_so_list-201108311551.patch" Content-length: 878 Index: gdb/solib.c =================================================================== RCS file: /cvs/src/src/gdb/solib.c,v retrieving revision 1.153 diff -u -p -r1.153 solib.c --- gdb/solib.c 30 Aug 2011 02:48:05 -0000 1.153 +++ gdb/solib.c 31 Aug 2011 19:20:44 -0000 @@ -1226,7 +1226,22 @@ reload_shared_libraries_1 (int from_tty) && filename_cmp (found_pathname, so->so_name) != 0)) { if (so->objfile && ! (so->objfile->flags & OBJF_USERLOADED)) - free_objfile (so->objfile); + { + struct so_list *pivot; + int used = 0; + + for (pivot = so_list_head; pivot != NULL; pivot = pivot->next) + { + if (pivot != so && pivot->objfile == so->objfile) + { + used = 1; + break; + } + } + + if (!used) + free_objfile (so->objfile); + } remove_target_sections (so->abfd); free_so_symbols (so); } --------------020403060807000001080202--