| Summary: | gdb crashed when I tried get backtrace | ||
|---|---|---|---|
| Product: | gdb | Reporter: | mikhail.v.gavrilov |
| Component: | gdb | Assignee: | Keith Seitz <keiths> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | keiths, sergiodj, ssbssa |
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
mikhail.v.gavrilov
2018-10-13 17:44:08 UTC
Trying debugging core file of gdb produce new crash of gdb which try debug core file of gdb. This is a recursion!!! If I remove debuginfo files of gdb then gdb able opens core of gdb file successfully, but without debuginfo it is useless. Patch posted upstream by Keith Seitz: https://sourceware.org/ml/gdb-patches/2018-10/msg00299.html (In reply to Sergio Durigan Junior from comment #2) > Patch posted upstream by Keith Seitz: > > https://sourceware.org/ml/gdb-patches/2018-10/msg00299.html This patch doesn't fix this issue. This bug is a different problem. The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c24bdb023c8e1fa969d6eb945059fa8ed0d490c7 commit c24bdb023c8e1fa969d6eb945059fa8ed0d490c7 Author: Keith Seitz <keiths@redhat.com> Date: Wed Jan 16 11:38:06 2019 -0800 Introduce dwarf2_cu::get_builder This patch is an attempt to deal with a variety of bugs reported where GDB segfaults attempting to access a dwarf2_cu's builder. In certain circumstances, this builder can be NULL. This is especially common when inheriting DIEs via inlined subroutines in other CUs. The test case demonstrates one such situation reported by users. See gdb/23773, rhbz1638798, and dups for other concrete examples. The approach taken here is to save the ancestor CU into the dwarf2_cu of all CUs with DIEs that are "imported." This can happen whenever follow_die_offset and friends are called. This essentially introduces a chain of CUs that caused the importation of a DIE from a CU. Whenever a builder is requested of a CU that has none, the ancestors are searched for the first one with a builder. A design side effect of this is that the builder can now only be accessed by getter and setter methods because the builder itself is private. The bulk of the patch is relatively mindless text conversion from "cu->builder" to "cu->get_builder ()". I've included one test which was derived from one (of the many) bugs reported on the issue in both sourceware and Fedora bugzillas. gdb/ChangeLog: PR gdb/23773 * dwarf2read.c (dwarf2_cu) <ancestor>: New field. <builder>: Rename to .. <m_builder>: ... this and make private. (dwarf2_cu::get_builder): New method. Change all users of `builder' to use this method. (dwarf2_start_symtab): Move to ... (dwarf2_cu::start_symtab): ... here. Update all callers (setup_type_unit_groups): Move to ... (dwarf2_cu::setup_type_unit_groups): ... here. Update all callers. (dwarf2_cu::reset_builder): New method. (process_full_compunit, process_full_type_unit): Use dwarf2_cu::reset_builder. (follow_die_offset): Record the ancestor CU if it is different from the followed DIE's CU. (follow_die_sig_1): Likewise. gdb/testsuite/ChangeLog: PR gdb/23773 * gdb.dwarf2/inlined_subroutine-inheritance.exp: New file. (In reply to Sourceware Commits from comment #4) > The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=c24bdb023c8e1fa969d6eb945059fa8ed0d490c7 > > commit c24bdb023c8e1fa969d6eb945059fa8ed0d490c7 > Author: Keith Seitz <keiths@redhat.com> > Date: Wed Jan 16 11:38:06 2019 -0800 > > Introduce dwarf2_cu::get_builder > > This patch is an attempt to deal with a variety of bugs reported where > GDB segfaults attempting to access a dwarf2_cu's builder. In certain > circumstances, this builder can be NULL. This is especially common > when inheriting DIEs via inlined subroutines in other CUs. The test > case demonstrates one such situation reported by users. See gdb/23773, > rhbz1638798, and dups for other concrete examples. > > The approach taken here is to save the ancestor CU into the dwarf2_cu of > all CUs with DIEs that are "imported." This can happen whenever > follow_die_offset and friends are called. This essentially introduces a > chain of CUs that caused the importation of a DIE from a CU. Whenever > a builder is requested of a CU that has none, the ancestors are searched > for the first one with a builder. > > A design side effect of this is that the builder can now only be > accessed by getter and setter methods because the builder itself > is private. > > The bulk of the patch is relatively mindless text conversion from > "cu->builder" to "cu->get_builder ()". I've included one test which > was derived from one (of the many) bugs reported on the issue in both > sourceware and Fedora bugzillas. > > gdb/ChangeLog: > > PR gdb/23773 > * dwarf2read.c (dwarf2_cu) <ancestor>: New field. > <builder>: Rename to .. > <m_builder>: ... this and make private. > (dwarf2_cu::get_builder): New method. Change all users of > `builder' to use this method. > (dwarf2_start_symtab): Move to ... > (dwarf2_cu::start_symtab): ... here. Update all callers > (setup_type_unit_groups): Move to ... > (dwarf2_cu::setup_type_unit_groups): ... here. Update all > callers. > (dwarf2_cu::reset_builder): New method. > (process_full_compunit, process_full_type_unit): Use > dwarf2_cu::reset_builder. > (follow_die_offset): Record the ancestor CU if it is different > from the followed DIE's CU. > (follow_die_sig_1): Likewise. > > gdb/testsuite/ChangeLog: > > PR gdb/23773 > * gdb.dwarf2/inlined_subroutine-inheritance.exp: New file. Can this be closed? (In reply to Hannes Domani from comment #5) > (In reply to Sourceware Commits from comment #4) > > The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > > h=c24bdb023c8e1fa969d6eb945059fa8ed0d490c7 > > > > commit c24bdb023c8e1fa969d6eb945059fa8ed0d490c7 > > Author: Keith Seitz <keiths@redhat.com> > > Date: Wed Jan 16 11:38:06 2019 -0800 > > > > Introduce dwarf2_cu::get_builder > > Can this be closed? Certainly seems like this was fixed a long time ago. Thank you for bringing this to my attention! |