From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28969 invoked by alias); 16 Jun 2003 13:49:47 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28957 invoked from network); 16 Jun 2003 13:49:46 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 16 Jun 2003 13:49:46 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19RuNX-0002pn-00 for ; Mon, 16 Jun 2003 08:50:35 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19RuMi-0004lM-00 for ; Mon, 16 Jun 2003 09:49:44 -0400 Date: Mon, 16 Jun 2003 13:49:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Crasher in dwarf2-frame.c - memory reuse Message-ID: <20030616134944.GA17095@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00316.txt.bz2 [This is Debian bug #197226.] If you take this file: #include int main(void) { char *temp; temp = malloc(100); free(temp); return 0; } And do this, with a compiler using DWARF-2: gcc -g -o t t.c gdb ./t b main r n [repeat n until the program exits] shell gcc -g -o t t.c r n Then GDB will segfault. It looks like this: #0 dwarf2_frame_find_fde (pc=0xbfffeb10) at /nevyn/local/gdb/gdb-5.3.20030606/gdb/dwarf2-frame.c:1002 1002 if (*pc >= fde->initial_location + offset #1 0x0813c71b in dwarf2_frame_p (pc=134513276) at /nevyn/local/gdb/gdb-5.3.20030606/gdb/dwarf2-frame.c:687 687 if (dwarf2_frame_find_fde (&pc)) (gdb) p *((struct dwarf2_fde *) objfile->sym_private) $2 = {cie = 0x828133c, initial_location = 134513500, address_range = 53, instructions = 0x8281330 "A\016\b\205\002B\r\005R.\020", end = 0x828133c "", next = 0x828433c} (gdb) p *((struct dwarf2_fde *) objfile->sym_private).next $3 = {cie = 0x82841c0, initial_location = 136856048, address_range = 136856096, instructions = 0x8284250 "\201", end = 0x8283d74 "\021", next = 0x8283d44} (gdb) p *((struct dwarf2_fde *) objfile->sym_private).next.next $4 = {cie = 0x1, initial_location = 2, address_range = 0, instructions = 0x0, end = 0x17e0
, next = 0x10} So something corrupt gets on to the FDE list. I love automated tools: ==17516== Invalid read of size 4 ==17516== at 0x813CB98: dwarf2_frame_find_fde (dwarf2-frame.c:1002) ==17516== by 0x813C71A: dwarf2_frame_p (dwarf2-frame.c:687) ==17516== by 0x8103EF8: frame_unwind_find_by_pc (frame-unwind.c:94) ==17516== by 0x8101C62: frame_register_unwind (frame.c:520) ==17516== Address 0x416EF718 is 1648 bytes inside a block of size 4072 free'd ==17516== at 0x4015D6A4: free (vg_clientfuncs.c:185) ==17516== by 0x80FEE97: xfree (utils.c:1167) ==17516== by 0x403060C7: _obstack_free (in /lib/libc-2.3.1.so) ==17516== by 0x80ADB92: reread_symbols (symfile.c:1951) So, reread_symbols frees the objfile, but does not clear sym_private. Clearing it in reread_symbols fixes the crash, but presumably leaks memory. How are we supposed to clean up the FDE list? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer