Crasher in dwarf2-frame.c - memory reuse

Crasher in dwarf2-frame.c - memory reuse

[Daniel Jacobowitz]

[This is Debian bug #197226.]

If you take this file:
#include <stdlib.h>

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 <Address 0x17e0 out of bounds>, 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

Re: Crasher in dwarf2-frame.c - memory reuse

[Andrew Cagney]

> 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?

       fde = (struct dwarf2_fde *)
         obstack_alloc (&unit->objfile->psymbol_obstack,
                        sizeof (struct dwarf2_fde));

so won't the symbol table free, free that memory?

Andrew

Re: Crasher in dwarf2-frame.c - memory reuse

[Daniel Jacobowitz]

On Mon, Jun 16, 2003 at 05:00:20PM -0400, Andrew Cagney wrote:
> >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?
> 
>       fde = (struct dwarf2_fde *)
>         obstack_alloc (&unit->objfile->psymbol_obstack,
>                        sizeof (struct dwarf2_fde));
> 
> so won't the symbol table free, free that memory?

Silly me.  I thought it was malloc'd.  In that case the fix is obvious;
I'll get it in a little bit.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Crasher in dwarf2-frame.c - memory reuse

[Andrew Cagney]

> On Mon, Jun 16, 2003 at 05:00:20PM -0400, Andrew Cagney wrote:
> 
>> >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?
> 
>> 
>>       fde = (struct dwarf2_fde *)
>>         obstack_alloc (&unit->objfile->psymbol_obstack,
>>                        sizeof (struct dwarf2_fde));
>> 
>> so won't the symbol table free, free that memory?
> 
> 
> Silly me.  I thought it was malloc'd.  In that case the fix is obvious;
> I'll get it in a little bit.

[it was one of the things I noted when giving marks patch the once over 
- it got rid of michaelL's memory leak]

BTW, there are lots of other places that should also use obstacks - the 
architecture vector for instance.

Andrew