From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19916 invoked by alias); 13 Dec 2007 01:58:11 -0000 Received: (qmail 19902 invoked by uid 22791); 13 Dec 2007 01:58:11 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Dec 2007 01:58:03 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id lBD1vxWJ016037 for ; Wed, 12 Dec 2007 17:57:59 -0800 Received: from wa-out-1112.google.com (wafm16.prod.google.com [10.114.189.16]) by zps36.corp.google.com with ESMTP id lBD1vFmY004831 for ; Wed, 12 Dec 2007 17:57:58 -0800 Received: by wa-out-1112.google.com with SMTP id m16so730710waf.20 for ; Wed, 12 Dec 2007 17:57:58 -0800 (PST) Received: by 10.114.199.1 with SMTP id w1mr1597049waf.38.1197511078809; Wed, 12 Dec 2007 17:57:58 -0800 (PST) Received: by 10.115.107.7 with HTTP; Wed, 12 Dec 2007 17:57:58 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 01:58:00 -0000 From: "Doug Evans" To: gdb@sourceware.org Subject: protection from dangling pointers in dwarf info when .so's go away MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00082.txt.bz2 [target = i386-linux] Hi. I'm debugging a gdb segv where a .so provides TYPE_VPTR_{BASETYPE,FIELDNO} while gdb is evaluating an expression. e.g. $ gdb my-prog (gdb) b foo (gdb) run Breakpoint 1 hit (gdb) p myclass->bar () At this point the "struct type" for myclass has type->main_type->vptr_basetype pointing into the obstack for the .so. If I run the program again and do the same thing, i.e. (gdb) run Start from the beginning? y Breakpoint 1 hit (gdb) p myclass->bar () --> segv because when the program was rerun all the obstacks for the .so's got freed (by objfile_purge_solibs) leaving a bogus value in vptr_basetype. How is this supposed to work? Is it the case that vptr_basetype for myclass should never have gotten assigned a value pointing into a .so (or any other obstack)? Or is gdb supposed to have cleaned up after itself when the .so data got freed? Or something else? Any guidance on where the fix should go is appreciated. I suppose an easy solution is to toss out all info, not just for .so's, though that will slow down re-runs. Thanks.