This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
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