[Bug gdb/26336] New: corefile.exp regression for unix/-m32 on x86_64

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/26336] New: corefile.exp regression for unix/-m32 on x86_64

Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26336

            Bug ID: 26336
           Summary: corefile.exp regression for unix/-m32 on x86_64
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: kevinb at redhat dot com
  Target Milestone: ---

Overview:

gdb.base/corefile.exp is showing an unexpected failure and an unresolved
testcase when testing against unix/-m32.

Steps to Reproduce:

1) Fetch and build upstream GDB sources in the normal fashion for x86_64.

2) Test using the following command:

make check RUNTESTFLAGS="--target_board unix/-m32" TESTS="gdb.base/corefile.exp

Actual Results:

                === gdb Summary ===

# of expected passes            28
# of unexpected failures        1
# of unresolved testcases       1


Expected Results:

                === gdb Summary ===

# of expected passes            30

Build Date & Hardware:

I first noticed this problem on July 29, 2020.

Hardware is x86_64 VMs running on an x86_64 virtualization host.  I've
reproduced this problem using Fedora 28, 29, 31, and 32.

Additional Information:

I've isolated the commit which first caused the regression:

From 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 Mon Sep 17 00:00:00 2001
From: Pedro Alves <[hidden email]>
Date: Fri, 10 Jan 2020 20:06:08 +0000
Subject: [PATCH] Multi-target support

Below is the relevant portion of the log file. Once -m32 binaries and corefile
are created, the sequence shown below (with a suitable pid for the attach) may
be used to reproduce the problem when running GDB by hand.

spawn
/mesquite2/sourceware-git/f29-bisect/bld/gdb/testsuite/outputs/gdb.base/corefile/corefile
sleep
spawn /mesquite2/sourceware-git/f29-bisect/bld/gdb/testsuite/../../gdb/gdb -nw
-nx -data-directory
/mesquite2/sourceware-git/f29-bisect/bld/gdb/testsuite/../data-directory
GNU gdb (GDB) 10.0.50.20200110-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) set height 0
(gdb) set width 0
(gdb) core-file
/mesquite2/sourceware-git/f29-bisect/bld/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
[New LWP 15497]
Core was generated by
`/mesquite2/sourceware-git/f29-bisect/bld/gdb/testsuite/outputs/gdb.base/corefil'.
Program terminated with signal SIGABRT, Aborted.
#0  0xf7f7cb29 in __kernel_vsyscall ()
(gdb) PASS: gdb.base/corefile.exp: attach: load core again
info files
Local core dump file:
       
`/mesquite2/sourceware-git/f29-bisect/bld/gdb/testsuite/outputs/gdb.base/corefile/corefile.core',
file type elf32-i386.
        0x08048000 - 0x08049000 is load1
        0x08049000 - 0x08049000 is load2
        0x0804a000 - 0x0804a000 is load3
        0x0804b000 - 0x0804c000 is load4
        0x0804c000 - 0x0804d000 is load5
        0x09a31000 - 0x09a53000 is load6
        0xf7ccc000 - 0xf7ccd000 is load7a
        0xf7ccd000 - 0xf7ccd000 is load7b
        0xf7ce5000 - 0xf7ce5000 is load8
        0xf7e09000 - 0xf7e09000 is load9
        0xf7e6e000 - 0xf7e6e000 is load10
        0xf7e6f000 - 0xf7e71000 is load11
        0xf7e71000 - 0xf7e72000 is load12
        0xf7e72000 - 0xf7e75000 is load13
        0xf7e75000 - 0xf7e76000 is load14a
        0xf7e76000 - 0xf7e76000 is load14b
        0xf7e7f000 - 0xf7e7f000 is load15
        0xf7f0e000 - 0xf7f0e000 is load16
        0xf7f46000 - 0xf7f47000 is load17
        0xf7f47000 - 0xf7f48000 is load18
        0xf7f75000 - 0xf7f77000 is load19
        0xf7f77000 - 0xf7f79000 is load20
        0xf7f79000 - 0xf7f7c000 is load21
        0xf7f7c000 - 0xf7f7d000 is load22
        0xf7f7d000 - 0xf7f7e000 is load23
        0xf7f7e000 - 0xf7f7e000 is load24
        0xf7f9b000 - 0xf7f9b000 is load25
        0xf7fa6000 - 0xf7fa7000 is load26
        0xf7fa7000 - 0xf7fa8000 is load27
        0xff9d1000 - 0xff9f3000 is load28
(gdb) PASS: gdb.base/corefile.exp: attach: sanity check we see the core file
attach 15741
/ironwood1/sourceware-git/f29-bisect/bld/../../worktree-bisect/gdb/dwarf2-frame.c:1009:
internal-error: dwarf2_frame_cache* dwarf2_frame_cache(frame_info*, void**):
Assertion `fde != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.base/corefile.exp: attach: with
core (GDB internal error)
Resyncing due to internal error.

Partial backtrace against HEAD:

#0  internal_error (
    file=0xb71d48
"/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/dwarf2/frame.c",
line=1013,
    fmt=0xb719df "%s: Assertion `%s' failed.")
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdbsupport/errors.cc:51
#1  0x00000000005a353d in dwarf2_frame_cache (this_frame=0x112a980,
this_cache=0x112a998)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/dwarf2/frame.c:1013
#2  0x00000000005a3e1c in dwarf2_frame_this_id (this_frame=0x112a980,
this_cache=0x112a998, this_id=0x112a9e0)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/dwarf2/frame.c:1226
#3  0x000000000066ba43 in compute_frame_id (fi=0x112a980)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/frame.c:561
#4  0x000000000066bb90 in get_frame_id (fi=0x112a980)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/frame.c:593
#5  0x0000000000944589 in
scoped_restore_current_thread::scoped_restore_current_thread (During symbol
reading: Child DIE 0x433e63 and its abstract origin 0x44ca00 have different
parents
this=0x7fffffffc8e8)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/thread.c:1458
#6  0x00000000004b4f19 in
scoped_restore_current_pspace_and_thread::scoped_restore_current_pspace_and_thread
(During symbol reading: .debug_line address at offset 0x17268e is 0 [in module
/mesquite2/sourceware-git/f32-amd64-corefile/bld-m32/gdb/gdb]
this=0x7fffffffc8e0)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/progspace-and-thread.h:29
#7  0x00000000006554d3 in remove_target_sections (owner=0x12edf30)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/exec.c:798
#8  0x00000000008e45a2 in symfile_free_objfile (objfile=0x12edf30)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/symfile.c:3742
#9  0x00000000004458a4 in std::__invoke_impl<void, void (*&)(objfile*),
objfile*> (
    __f=@0x114dca0: 0x8e4583 <symfile_free_objfile(objfile*)>) at
/usr/include/c++/10/bits/invoke.h:60
#10 0x00000000004443a9 in std::__invoke_r<void, void (*&)(objfile*), objfile*>
(
    __fn=@0x114dca0: 0x8e4583 <symfile_free_objfile(objfile*)>) at
/usr/include/c++/10/bits/invoke.h:153
#11 0x0000000000442fec in std::_Function_handler<void (objfile*), void
(*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=...,
__args#0=@0x7fffffffca60: 0x12edf30) at
/usr/include/c++/10/bits/std_function.h:291
#12 0x00000000007c6167 in std::function<void (objfile*)>::operator()(objfile*)
const (this=0x114dca0, __args#0=0x12edf30)
    at /usr/include/c++/10/bits/std_function.h:622
#13 0x00000000007c5c58 in gdb::observers::observable<objfile*>::notify
(this=0xfd2dc0 <gdb::observers::free_objfile>,
    args#0=0x12edf30)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/../gdbsupport/observable.h:106
#14 0x00000000007c275d in objfile::~objfile (this=0x12edf30,
__in_chrg=<optimized out>)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/objfiles.c:521
#15 0x00000000007c7774 in std::_Sp_counted_ptr<objfile*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x12ee190)
    at /usr/include/c++/10/bits/shared_ptr_base.h:380
#16 0x00000000004b97c9 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x12ee190)
    at /usr/include/c++/10/bits/shared_ptr_base.h:158
#17 0x00000000004b57ab in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x1220308,
    __in_chrg=<optimized out>) at
/usr/include/c++/10/bits/shared_ptr_base.h:733
#18 0x00000000007c5668 in std::__shared_ptr<objfile,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x1220300,
    __in_chrg=<optimized out>) at
/usr/include/c++/10/bits/shared_ptr_base.h:1183
#19 0x00000000007c5684 in std::shared_ptr<objfile>::~shared_ptr
(this=0x1220300, __in_chrg=<optimized out>)
    at /usr/include/c++/10/bits/shared_ptr.h:121
#20 0x00000000007f43f0 in
__gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> >
>::destroy<std::shared_ptr<objfile> > (this=0x1199e40, __p=0x1220300) at
/usr/include/c++/10/ext/new_allocator.h:156
#21 0x00000000007f3df1 in
std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> >
> >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x1220300) at
/usr/include/c++/10/bits/alloc_traits.h:531
#22 0x00000000007f3a6e in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::_M_erase (
    this=0x1199e40, __position=std::shared_ptr<objfile> (expired, weak count 1)
= {get() = 0x12edf30})
    at /usr/include/c++/10/bits/stl_list.h:1925
#23 0x00000000007f3462 in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::erase (
    this=0x1199e40, __position=std::shared_ptr<objfile> (expired, weak count 1)
= {get() = 0x12edf30})
    at /usr/include/c++/10/bits/list.tcc:158
#24 0x00000000007f1e49 in program_space::remove_objfile (this=0x1199e00,
objfile=0x12edf30)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/progspace.c:207
#25 0x00000000007c26e8 in objfile::unlink (this=0x12edf30)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/objfiles.c:497
#26 0x00000000007c39fa in objfile_purge_solibs ()
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/objfiles.c:904
#27 0x00000000008b462f in no_shared_libraries (ignored=0x0, from_tty=1)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/solib.c:1236
#28 0x0000000000927a07 in target_pre_inferior (from_tty=1)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/target.c:1900
#29 0x00000000006ee394 in attach_command (args=0x12a9227 "140459", from_tty=1)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/infcmd.c:2582

I wondered about why x86_64 works, but -m32 does not.  I ran them side-by-side
and found...

x86_64:

Thread 1 "gdb" hit Breakpoint 4, remove_target_sections (During symbol reading:
incomplete CFI data; unspecified registers (e.g., rax) at 0x653ccc
owner=0x12da6e0)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld/../../worktree-corefile/gdb/exec.c:798
798               scoped_restore_current_pspace_and_thread
restore_pspace_thread;
(top-gdb) c
Continuing.

Thread 1 "gdb" hit Breakpoint 6,
scoped_restore_current_thread::scoped_restore_current_thread
(this=0x7fffffffc8f8)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld/../../worktree-corefile/gdb/thread.c:1458
1458              m_selected_frame_id = get_frame_id (frame);
(top-gdb) s
get_frame_id (fi=0x1130bf0) at
/ironwood1/sourceware-git/f32-amd64-corefile/bld/../../worktree-corefile/gdb/frame.c:578
578       if (fi == NULL)
(top-gdb)
581       if (!fi->this_id.p)
(top-gdb)
590           gdb_assert (fi->level == 0);
(top-gdb) n
593           compute_frame_id (fi);
(top-gdb) s
compute_frame_id (fi=0x1130bf0) at
/ironwood1/sourceware-git/f32-amd64-corefile/bld/../../worktree-corefile/gdb/frame.c:550
550       gdb_assert (!fi->this_id.p);
(top-gdb) n
552       if (frame_debug)
(top-gdb) n
556       if (fi->unwind == NULL)
(top-gdb)
560       fi->this_id.value = outer_frame_id;
(top-gdb)
561       fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
(top-gdb) s
amd64_frame_this_id (this_frame=0x1130bf0, this_cache=0x1130c08,
this_id=0x1130c50)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld/../../worktree-corefile/gdb/amd64-tdep.c:2686
2686        amd64_frame_cache (this_frame, this_cache);
(top-gdb) up
#1  0x000000000066a143 in compute_frame_id (fi=0x1130bf0) at
/ironwood1/sourceware-git/f32-amd64-corefile/bld/../../worktree-corefile/gdb/frame.c:561
561       fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
(top-gdb) p fi->unwind->this_id
$10 = (frame_this_id_ftype *) 0x45ea70 <amd64_frame_this_id(frame_info*,
void**, frame_id*)>
(top-gdb)


-m32:

Thread 1 "gdb" hit Breakpoint 4, remove_target_sections (During symbol reading:
incomplete CFI data; unspecified registers (e.g., rax) at 0x6555cc
owner=0x12cc960)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/exec.c:798
798               scoped_restore_current_pspace_and_thread
restore_pspace_thread;
(top-gdb) b thread.c:1458
Breakpoint 6 at 0x944572: file
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/thread.c,
line 1458.
(top-gdb) del 5
(top-gdb) c
Continuing.

Thread 1 "gdb" hit Breakpoint 6,
scoped_restore_current_thread::scoped_restore_current_thread
(this=0x7fffffffc8e8)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/thread.c:1458
1458              m_selected_frame_id = get_frame_id (frame);
(top-gdb) s
get_frame_id (fi=0x112a980) at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/frame.c:578
578       if (fi == NULL)
(top-gdb) s
581       if (!fi->this_id.p)
(top-gdb)
590           gdb_assert (fi->level == 0);
(top-gdb) n
593           compute_frame_id (fi);
(top-gdb) s
compute_frame_id (fi=0x112a980) at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/frame.c:550
550       gdb_assert (!fi->this_id.p);
(top-gdb) n
552       if (frame_debug)
(top-gdb)
556       if (fi->unwind == NULL)
(top-gdb)
560       fi->this_id.value = outer_frame_id;
(top-gdb)
561       fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
(top-gdb) s
dwarf2_frame_this_id (this_frame=0x112a980, this_cache=0x112a998,
this_id=0x112a9e0)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/dwarf2/frame.c:1226
1226        dwarf2_frame_cache (this_frame, this_cache);
(top-gdb) up
#1  0x000000000066ba43 in compute_frame_id (fi=0x112a980)
    at
/ironwood1/sourceware-git/f32-amd64-corefile/bld-m32/../../worktree-corefile/gdb/frame.c:561
561       fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
(top-gdb) p fi->unwind->this_id
$7 = (frame_this_id_ftype *) 0x5a3df4 <dwarf2_frame_this_id(frame_info*,
void**, frame_id*)>

I.e. x86_64 is using the amd64 unwinder, but -m32 is using the dwarf2 unwinder.

(But I'm thinking that for this particular scenario, just getting to this point
where we're mucking about with unwinders at all might be the problem.)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/26336] corefile.exp regression for unix/-m32 on x86_64

Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26336

Kevin Buettner <kevinb at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/26336] corefile.exp regression for unix/-m32 on x86_64

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26336

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.1

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/26336] corefile.exp regression for unix/-m32 on x86_64

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26336

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <[hidden email]>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=27c7b875bd386d56fc75fb14cc83957bdc282812

commit 27c7b875bd386d56fc75fb14cc83957bdc282812
Author: Pedro Alves <[hidden email]>
Date:   Wed Aug 12 19:31:19 2020 +0100

    gdb.base/corefile.exp regression for unix/-m32 on x86_64 (PR 26336)

    gdb.base/corefile.exp is showing an unexpected failure and an
    unresolved testcase when testing against unix/-m32:

     (gdb) PASS: gdb.base/corefile.exp: attach: sanity check we see the core
file
     attach 15741
     gdb/dwarf2-frame.c:1009: internal-error: dwarf2_frame_cache*
dwarf2_frame_cache(frame_info*, void**): Assertion `fde != NULL' failed.
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.
     Quit this debugging session? (y or n) FAIL: gdb.base/corefile.exp: attach:
with core (GDB internal error)
     Resyncing due to internal error.

    This regressed with:

     From 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 Mon Sep 17 00:00:00 2001
     From: Pedro Alves <[hidden email]>
     Date: Fri, 10 Jan 2020 20:06:08 +0000
     Subject: [PATCH] Multi-target support

    The assertion is here:

     #0  internal_error (file=0xbffffccb0 <error: Cannot access memory at
address 0xbffffccb0>, line=0, fmt=0x555556327320 "en_US.UTF-8") at sr
     c/gdbsupport/errors.cc:51
     #1  0x00005555557d4e45 in dwarf2_frame_cache (this_frame=0x55555672f950,
this_cache=0x55555672f968) at src/gdb/dwarf2/frame.c:1013
     #2  0x00005555557d5886 in dwarf2_frame_this_id (this_frame=0x55555672f950,
this_cache=0x55555672f968, this_id=0x55555672f9b0) at src/gdb/d
     warf2/frame.c:1226
     #3  0x00005555558b184e in compute_frame_id (fi=0x55555672f950) at
src/gdb/frame.c:558
     #4  0x00005555558b19b2 in get_frame_id (fi=0x55555672f950) at
src/gdb/frame.c:588
     #5  0x0000555555bda338 in
scoped_restore_current_thread::scoped_restore_current_thread
(this=0x7fffffffd0d8) at src/gdb/thread.c:1458
     #6  0x00005555556ce41f in
scoped_restore_current_pspace_and_thread::scoped_restore_current_pspace_and_thread
(During symbol reading: .debug_line address at offset 0x1db2d3
     is 0 [in module /home/pedro/gdb/cascais-builds/binutils-gdb/gdb/gdb]
     this=0x7fffffffd0d0) at src/gdb/progspace-and-thread.h:29
     #7  0x0000555555898ea6 in remove_target_sections (owner=0x555556935550) at
src/gdb/exec.c:798
     #8  0x0000555555b700b6 in symfile_free_objfile (objfile=0x555556935550) at
src/gdb/symfile.c:3742
     #9  0x000055555565050e in std::_Function_handler<void (objfile*), void
(*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=...,
__args#0=@0x7fffffffd190
     : 0x555556935550) at /usr/include/c++/9/bits/std_function.h:300
     #10 0x0000555555a3053d in std::function<void
(objfile*)>::operator()(objfile*) const (this=0x555556752a20,
__args#0=0x555556935550) at /usr/include/c++/9/bits/std_function.
     h:688
     #11 0x0000555555a2ff01 in gdb::observers::observable<objfile*>::notify
(this=0x5555562eaa80 <gdb::observers::free_objfile>, args#0=0x555556935550) at
/net/cascais.nfs/gdb/b
     inutils-gdb/src/gdb/../gdbsupport/observable.h:106
     #12 0x0000555555a2c56a in objfile::~objfile (this=0x555556935550,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:521
     #13 0x0000555555a31d46 in std::_Sp_counted_ptr<objfile*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c1f6f0) at
/usr/include/c++/9/bits/shared_ptr_base.h:377
     #14 0x00005555556d3444 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x555556c1f6f0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
     #15 0x00005555556cec77 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x555556b99ee8, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr_base.h:730
     #16 0x0000555555a2f8da in std::__shared_ptr<objfile,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556b99ee0,
__in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
     #17 0x0000555555a2f8fa in std::shared_ptr<objfile>::~shared_ptr
(this=0x555556b99ee0, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr.h:103
     #18 0x0000555555a63fba in
__gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> >
>::destroy<std::shared_ptr<objfile> > (this=0x55555679f0c0, __p=0x555556b99ee0)
at /usr/include/c++/9/ext/new_allocator.h:153
     #19 0x0000555555a638fb in
std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> >
> >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556b99ee0) at
/usr/include/c++/9/bits/alloc_traits.h:497
     #20 0x0000555555a6351c in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x55555679f0c0,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556935550}) at /usr/include/c++/9/bits/stl_list.h:1921
     #21 0x0000555555a62dab in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::erase (this=0x55555679f0c0,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556935550}) at /usr/include/c++/9/bits/list.tcc:158
     #22 0x0000555555a614dd in program_space::remove_objfile
(this=0x55555679f080, objfile=0x555556935550) at src/gdb/progspace.c:207
     #23 0x0000555555a2c4dc in objfile::unlink (this=0x555556935550) at
src/gdb/objfiles.c:497
     #24 0x0000555555a2da65 in objfile_purge_solibs () at
src/gdb/objfiles.c:904
     #25 0x0000555555b3af74 in no_shared_libraries (ignored=0x0, from_tty=1) at
src/gdb/solib.c:1236
     #26 0x0000555555bbafc7 in target_pre_inferior (from_tty=1) at
src/gdb/target.c:1900
     #27 0x0000555555940afb in attach_command (args=0x5555563277c7 "15741",
from_tty=1) at src/gdb/infcmd.c:2582
     ...


    The problem is that the multi-target commit added a
    scoped_restore_current_thread to remove_target_sections (frame #7
    above).  scoped_restore_current_thread's ctor fetches the selected
    frame's frame id.  If the frame had not had its frame id computed yet,
    it is computed then (frame #4 above).  Because it has been determined
    earlier that the frame's unwinder is the DWARF unwinder, we end up
    here:

     static struct dwarf2_frame_cache *
     dwarf2_frame_cache (struct frame_info *this_frame, void **this_cache)
     {
     ...
       /* Find the correct FDE.  */
       fde = dwarf2_frame_find_fde (&pc1, &cache->per_objfile);
       gdb_assert (fde != NULL);

    And, that assertion fails.  The assertion is reasonable, because the
    DWARF unwinder only claims the frame if it managed to find the FDE
    earlier (in dwarf2_frame_sniffer).

    (unix/-m32 is thus really a red herring here -- it's just that on
    x86_64 -m64, the frame is not claimed by the DWARF unwinder.)

    The reason the assertion is failing, is because the objfile that
    contains the FDE has been removed from the objfiles list already when
    we get here (frame #22 above).  This suggests that the fix should be
    to invalidate DWARF frames when their objfile is removed.  Or to keep
    it simple and safe, invalidate the frame cache when an objfile is
    removed.  That is what this commit does.

    OOC, I checked why is it that when you unload a file with plain "(gdb)
    file", we don't hit the assertion.  It must be because we're already
    flushing the frame cache somewhere else in that case.  And indeed, we
    flush the frame cache here:

     (gdb) bt
     #0  reinit_frame_cache () at src/gdb/frame.c:1857
     #1  0x0000555555ad1ad6 in registers_changed_ptid (target=0x0, ptid=...) at
src/gdb/regcache.c:470
     #2  0x0000555555ad1b58 in registers_changed () at src/gdb/regcache.c:485
     #3  0x00005555558d095e in set_target_gdbarch (new_gdbarch=0x555556d5f5b0)
at src/gdb/gdbarch.c:5528
     #4  0x0000555555677175 in set_gdbarch_from_file (abfd=0x0) at
src/gdb/arch-utils.c:601
     #5  0x0000555555897c6b in exec_file_attach (filename=0x0, from_tty=1) at
src/gdb/exec.c:409
     #6  0x000055555589852d in exec_file_command (args=0x0, from_tty=1) at
src/gdb/exec.c:571
     #7  0x00005555558985a1 in file_command (arg=0x0, from_tty=1) at
src/gdb/exec.c:583
     #8  0x000055555572b55f in do_const_cfunc (c=0x55555672e200, args=0x0,
from_tty=1) at src/gdb/cli/cli-decode.c:95
     #9  0x000055555572f3d3 in cmd_func (cmd=0x55555672e200, args=0x0,
from_tty=1) at src/gdb/cli/cli-decode.c:2181
     #10 0x0000555555be1ecc in execute_command (p=0x555556327804 "",
from_tty=1) at src/gdb/top.c:668
     #11 0x0000555555895427 in command_handler (command=0x555556327800 "file")
at src/gdb/event-top.c:588
     #12 0x00005555558958af in command_line_handler (rl=...) at
src/gdb/event-top.c:773
     #13 0x0000555555894b3e in gdb_rl_callback_handler (rl=0x55555a09e240
"file") at src/gdb/event-top.c:219
     #14 0x0000555555ccfeec in rl_callback_read_char () at
src/readline/readline/callback.c:281
     #15 0x000055555589495a in gdb_rl_callback_read_char_wrapper_noexcept () at
src/gdb/event-top.c:177
     #16 0x0000555555894a08 in gdb_rl_callback_read_char_wrapper
(client_data=0x555556327520) at src/gdb/event-top.c:194
     #17 0x00005555558952a5 in stdin_event_handler (error=0,
client_data=0x555556327520) at src/gdb/event-top.c:516
     #18 0x0000555555e027d6 in handle_file_event (file_ptr=0x555558d20840,
ready_mask=1) at src/gdbsupport/event-loop.cc:548
     #19 0x0000555555e02d88 in gdb_wait_for_event (block=1) at
src/gdbsupport/event-loop.cc:673
     #20 0x0000555555e01c42 in gdb_do_one_event () at
src/gdbsupport/event-loop.cc:215
     #21 0x00005555559c47c2 in start_event_loop () at src/gdb/main.c:356
     #22 0x00005555559c490d in captured_command_loop () at src/gdb/main.c:416
     #23 0x00005555559c6217 in captured_main (data=0x7fffffffdc00) at
src/gdb/main.c:1253
     #24 0x00005555559c6289 in gdb_main (args=0x7fffffffdc00) at
src/gdb/main.c:1268
     #25 0x0000555555621756 in main (argc=3, argv=0x7fffffffdd18) at
src/gdb/gdb.c:32

    gdb/ChangeLog:

            PR gdb/26336
            * progspace.c (program_space::remove_objfile): Invalidate the
            frame cache.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/26336] corefile.exp regression for unix/-m32 on x86_64

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26336

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Fix merged.

--
You are receiving this mail because:
You are on the CC list for the bug.