Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Thu, Sep 3, 2009 at 8:54 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:

> I think elimination of failing asserts:
>  http://sourceware.org/ml/gdb-patches/2009-09/msg00062.html
> should be considered release blocking.

I think there is another release blocker:

For the last two weeks we've been running with a beta release built on
20090824 from CVS Head, and have several (more than 20) reports of
SIGSGV in GDB, when restarting the inferior.

Yesterday I got a repro and analyzed it. AFAICT, the problem is that
in (recently added) clean_up_objfile_types, we make copies of types
from unloaded solibs.

Names of these types come from the .debug_info of the corresponding solib.

If solib is small, its .debug_info is obstack_alloc()ed and still
valid at the time of clean_up_objfile_types call.
If it is large, it gets bfd_mmap()ed in dwarf2_read_section(), and is
munmapped in dwarf2_per_objfile_cleanup, which executes *before*
clean_up_objfile_types. By the time we come to strdup in
copy_type_recursive (called from clean_up_objfile_types), the name of
the type has been munmapped.

Here is the crash stack (sorry about gmail line wrapping):

#0  0x00007f0c16a60a30 in strlen () from /usr/lib64/libc.so.6
#1  0x000000000062f896 in xstrdup (s=0x7f0c0ef9ce64 <Address
0x7f0c0ef9ce64 out of bounds>) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/libiberty/xstrdup.c:33
#2  0x00000000004e5769 in copy_type_recursive (objfile=<value
optimized out>, type=0x17f2a3b8, copied_types=0x17ec8f60)
   at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/gdbtypes.c:2877
#3  0x000000000047200b in clean_up_objfile_types (objfile=0x8903b80,
datum=<value optimized out>)
   at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/python/python-type.c:548
#4  0x000000000040300b in clear_objfile_data (objfile=0x8903b80) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:1036
#5  0x0000000000403a56 in objfile_free_data (objfile=0x8903b80) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:1019
#6  free_objfile (objfile=0x8903b80) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:453
#7  0x0000000000403bec in objfile_purge_solibs () at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:758
#8  0x00000000004f0545 in target_pre_inferior (from_tty=0) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/target.c:1897
#9  0x00000000004c1b4c in run_command_1 (args=0x0, from_tty=0,
tbreak_at_main=0) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/infcmd.c:482

The 0x7f0c0ef9ce64 used to point to "int32" in a DWARF2 section which
has since been removed/unmapped.

I am still working on a stand-alone repro case.

-- 
Paul Pluzhnikov