[Bug gdb/28080] New: detach causes core dump

public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed

* [Bug gdb/28080] New: detach causes core dump
@ 2021-07-12 15:33 jonah at kichwacoders dot com
  2021-07-12 16:05 ` [Bug gdb/28080] " simark at simark dot ca
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: jonah at kichwacoders dot com @ 2021-07-12 15:33 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

            Bug ID: 28080
           Summary: detach causes core dump
           Product: gdb
           Version: 11.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: jonah at kichwacoders dot com
  Target Milestone: ---

Created attachment 13556
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13556&action=edit
backtrace

In GDB 11 prerelease there is a regression that doing a detach causes a core
dump (terminate called after throwing an instance of 'gdb_exception_error')

To reproduce, run a simple program like this "gdbserver :45511 simple" (using
gdbserver from the build, but it also failed using system gdbserver 9.2)

Then run gdb and do a "target remote localhost:45511" followed by a "detach".
Note that the target is not running when I do a detach below, but I believe
this is a reduced case of a more complicated test that is part of Eclipse CDT
testsuite[1]

(gdb) detach
Detaching from program:
target:/scratch/eclipse/src/cdt/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/data/launch/bin/TargetAvail.exe,
process 3671843
Detaching from process 3671843
Ending remote debugging.
[Inferior 1 (process 3671843) detached]
In main
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)


I have attached the backtrace for the error.

I did a git bisect and found that 408f66864a1a823591b26420410c982174c239a2
introduces the error which was part of the patch set that Simon pointed me at:
https://sourceware.org/pipermail/gdb-patches/2021-January/175040.html


[1]
https://ci.eclipse.org/cdt/view/Main%20(debug%20tests)/job/debug-tests-master-gdb-master/lastCompletedBuild/testReport/org.eclipse.cdt.tests.dsf.gdb.tests/OperationsWhileTargetIsRunningTest/detachWhileTargetRunningGDBAlive_gdbserver_/

This was done on Ubuntu 20.04 on x86_64 hardware:
$ lsb_release 
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
$ uname -a
Linux ditto 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
@ 2021-07-12 16:05 ` simark at simark dot ca
  2021-07-12 19:37 ` pedro at palves dot net
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: simark at simark dot ca @ 2021-07-12 16:05 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.1
                 CC|                            |simark at simark dot ca

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
  2021-07-12 16:05 ` [Bug gdb/28080] " simark at simark dot ca
@ 2021-07-12 19:37 ` pedro at palves dot net
  2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pedro at palves dot net @ 2021-07-12 19:37 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |pedro at palves dot net
           Assignee|unassigned at sourceware dot org   |pedro at palves dot net
   Last reconfirmed|                            |2021-07-12

--- Comment #1 from Pedro Alves <pedro at palves dot net> ---
Proposed fix here:
 https://sourceware.org/pipermail/gdb-patches/2021-July/180847.html

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
  2021-07-12 16:05 ` [Bug gdb/28080] " simark at simark dot ca
  2021-07-12 19:37 ` pedro at palves dot net
@ 2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
  2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-13 14:32 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

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

commit d7cb0ef35b112e35a3e9b4dc30ffd800c9d0a4fe
Author: Pedro Alves <pedro@palves.net>
Date:   Mon Jul 12 17:10:48 2021 +0100

    Fix detach with target remote (PR gdb/28080)

    Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop
    with threads running") regressed "detach" with "target remote":

     (gdb) detach
     Detaching from program: target:/any/program, process 3671843
     Detaching from process 3671843
     Ending remote debugging.
     [Inferior 1 (process 3671843) detached]
     In main
     terminate called after throwing an instance of 'gdb_exception_error'
     Aborted (core dumped)

    Here's the exception above being thrown:

     (top-gdb) bt
     #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote
connection closed") at src/gdbsupport/common-exceptions.cc:222
     #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040,
timeout=10000) at src/gdb/remote.c:9440
     #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1
(this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0,
is_notif=0x0) at src/gdb/remote.c:9928
     #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040,
buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
     #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command
(this=0x555556a11040, command_bytes=13, which_packet=14,
remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at
src/gdb/remote.c:12137
     #5  0x0000555555bc1b6c in remote_target::remote_hostio_close
(this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12455
     #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol
reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
     this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12462
     #7  0x0000555555c9274c in target_fileio_close (fd=3,
target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
     #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0,
stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
     #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:599
     #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:847
     #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:814
     #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:626
     #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:715
     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573
     #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at
/usr/include/c++/9/bits/shared_ptr_base.h:377
     #16 0x000055555572b7c8 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
     #17 0x00005555557263c3 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x555556bf0588, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr_base.h:730
     #18 0x0000555555ae745e in std::__shared_ptr<objfile,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580,
__in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
     #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr
(this=0x555556bf0580, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr.h:103
     #20 0x0000555555b1c1dc in
__gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> >
>::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580)
at /usr/include/c++/9/ext/new_allocator.h:153
     #21 0x0000555555b1bb1d in
std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> >
> >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at
/usr/include/c++/9/bits/alloc_traits.h:497
     #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
     #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
     #24 0x0000555555b19576 in program_space::remove_objfile
(this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
     #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at
src/gdb/objfiles.c:487
     #26 0x0000555555ae5a12 in objfile_purge_solibs () at
src/gdb/objfiles.c:875
     #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at
src/gdb/solib.c:1236
     #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at
src/gdb/infcmd.c:2769

    So frame #28 already detached the remote process, and then we're
    purging the shared libraries.  GDB had opened remote shared libraries
    via the target: sysroot, so it tries closing them.  GDBserver is
    tearing down already, so remote communication breaks down and we close
    the remote target and throw TARGET_CLOSE_ERROR.

    Note frame #14:

     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573

    That's a dtor, thus noexcept.  That's the reason for the
    std::terminate.

    Stepping back a bit, why do we still have open remote files if we've
    managed to detach already, and, we're debugging with "target remote"?
    The reason is that commit 408f66864a1a823591b26420410c982174c239a2
    makes detach_command hold a reference to the target, so the remote
    target won't be finally closed until frame #28 returns.  It's closing
    the target that invalidates target file I/O handles.

    This commit fixes the issue by not relying on target_close to
    invalidate the target file I/O handles, instead invalidate them
    immediately in remote_unpush_target.  So when GDB purges the solibs,
    and we end up in target_fileio_close (frame #7 above), there's nothing
    to do, and we don't try to talk with the remote target anymore.

    The regression isn't seen when testing with
    --target_board=native-gdbserver, because that does "set sysroot" to
    disable the "target:" sysroot, for test run speed reasons.  So this
    commit adds a testcase that explicitly tests detach with "set sysroot
    target:".

    gdb/ChangeLog:
    yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

            PR gdb/28080
            * remote.c (remote_unpush_target): Invalidate file I/O target
            handles.
            * target.c (fileio_handles_invalidate_target): Make extern.
            * target.h (fileio_handles_invalidate_target): Declare.

    gdb/testsuite/ChangeLog:
    yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

            PR gdb/28080
            * gdb.base/detach-sysroot-target.exp: New.
            * gdb.base/detach-sysroot-target.c: New.

    Reported-By: Jonah Graham <jonah@kichwacoders.com>

    Change-Id: I851234910172f42a1b30e731161376c344d2727d

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
                   ` (2 preceding siblings ...)
  2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
@ 2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
  2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-13 14:32 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

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

commit 3a76f8f489428bada97c9dea2145448a3e0f7135
Author: Pedro Alves <pedro@palves.net>
Date:   Mon Jul 12 18:03:22 2021 +0100

    Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)

    Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
    like this:

     (gdb) detach
     Detaching from program: target:/any/program, process 3671843
     Detaching from process 3671843
     Ending remote debugging.
     [Inferior 1 (process 3671843) detached]
     In main
     terminate called after throwing an instance of 'gdb_exception_error'
     Aborted (core dumped)

    Here's the exception above being thrown:

     (top-gdb) bt
     #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote
connection closed") at src/gdbsupport/common-exceptions.cc:222
     #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040,
timeout=10000) at src/gdb/remote.c:9440
     #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1
(this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0,
is_notif=0x0) at src/gdb/remote.c:9928
     #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040,
buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
     #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command
(this=0x555556a11040, command_bytes=13, which_packet=14,
remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at
src/gdb/remote.c:12137
     #5  0x0000555555bc1b6c in remote_target::remote_hostio_close
(this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12455
     #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol
reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
     this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12462
     #7  0x0000555555c9274c in target_fileio_close (fd=3,
target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
     #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0,
stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
     #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:599
     #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:847
     #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:814
     #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:626
     #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:715
     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573
     #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at
/usr/include/c++/9/bits/shared_ptr_base.h:377
     #16 0x000055555572b7c8 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
     #17 0x00005555557263c3 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x555556bf0588, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr_base.h:730
     #18 0x0000555555ae745e in std::__shared_ptr<objfile,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580,
__in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
     #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr
(this=0x555556bf0580, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr.h:103
     #20 0x0000555555b1c1dc in
__gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> >
>::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580)
at /usr/include/c++/9/ext/new_allocator.h:153
     #21 0x0000555555b1bb1d in
std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> >
> >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at
/usr/include/c++/9/bits/alloc_traits.h:497
     #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
     #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
     #24 0x0000555555b19576 in program_space::remove_objfile
(this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
     #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at
src/gdb/objfiles.c:487
     #26 0x0000555555ae5a12 in objfile_purge_solibs () at
src/gdb/objfiles.c:875
     #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at
src/gdb/solib.c:1236
     #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at
src/gdb/infcmd.c:2769

    Note frame #14:

     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573

    That's a dtor, thus noexcept.  That's the reason for the
    std::terminate.

    The previous patch fixed things such that the exception above isn't
    thrown anymore.  However, it's possible that e.g., the remote
    connection drops just while a user types "nosharedlibrary", or some
    other reason that leads to objfile::~objfile, and then we end up the
    same std::terminate problem.

    Also notice that frames #9-#11 are BFD frames:

     #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at
src/bfd/opncls.c:599
     #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at
src/bfd/opncls.c:847
     #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at
src/bfd/opncls.c:814

    BFD is written in C and thus throwing exceptions over such frames may
    either not clean up properly, or, may abort if bfd is not compiled
    with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
    all GCC ports do).

    Thus frame #8 seems like a good place to swallow exceptions.  More so
    since in this spot we already ignore target_fileio_close return
    errors.  That's what this commit does.  Without the previous fix, we'd
    see:

     (gdb) detach
     Detaching from program: target:/any/program, process 2197701
     Ending remote debugging.
     [Inferior 1 (process 2197701) detached]
     warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote
connection closed

    Note it prints a warning, which would still be a regression compared
    to GDB 10, if it weren't for the previous fix.

    gdb/ChangeLog:
    yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

            PR gdb/28080
            * gdb_bfd.c (gdb_bfd_close_warning): New.
            (gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
            try/catch and print warning on exception.
            (gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.

    Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
                   ` (3 preceding siblings ...)
  2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
@ 2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
  2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-13 14:35 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-11-branch branch has been updated by Pedro Alves
<palves@sourceware.org>:

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

commit 97c5ca8c34461194eb7900a2483a013d25858bbe
Author: Pedro Alves <pedro@palves.net>
Date:   Mon Jul 12 17:10:48 2021 +0100

    Fix detach with target remote (PR gdb/28080)

    Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop
    with threads running") regressed "detach" with "target remote":

     (gdb) detach
     Detaching from program: target:/any/program, process 3671843
     Detaching from process 3671843
     Ending remote debugging.
     [Inferior 1 (process 3671843) detached]
     In main
     terminate called after throwing an instance of 'gdb_exception_error'
     Aborted (core dumped)

    Here's the exception above being thrown:

     (top-gdb) bt
     #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote
connection closed") at src/gdbsupport/common-exceptions.cc:222
     #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040,
timeout=10000) at src/gdb/remote.c:9440
     #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1
(this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0,
is_notif=0x0) at src/gdb/remote.c:9928
     #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040,
buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
     #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command
(this=0x555556a11040, command_bytes=13, which_packet=14,
remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at
src/gdb/remote.c:12137
     #5  0x0000555555bc1b6c in remote_target::remote_hostio_close
(this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12455
     #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol
reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
     this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12462
     #7  0x0000555555c9274c in target_fileio_close (fd=3,
target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
     #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0,
stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
     #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:599
     #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:847
     #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:814
     #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:626
     #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:715
     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573
     #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at
/usr/include/c++/9/bits/shared_ptr_base.h:377
     #16 0x000055555572b7c8 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
     #17 0x00005555557263c3 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x555556bf0588, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr_base.h:730
     #18 0x0000555555ae745e in std::__shared_ptr<objfile,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580,
__in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
     #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr
(this=0x555556bf0580, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr.h:103
     #20 0x0000555555b1c1dc in
__gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> >
>::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580)
at /usr/include/c++/9/ext/new_allocator.h:153
     #21 0x0000555555b1bb1d in
std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> >
> >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at
/usr/include/c++/9/bits/alloc_traits.h:497
     #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
     #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
     #24 0x0000555555b19576 in program_space::remove_objfile
(this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
     #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at
src/gdb/objfiles.c:487
     #26 0x0000555555ae5a12 in objfile_purge_solibs () at
src/gdb/objfiles.c:875
     #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at
src/gdb/solib.c:1236
     #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at
src/gdb/infcmd.c:2769

    So frame #28 already detached the remote process, and then we're
    purging the shared libraries.  GDB had opened remote shared libraries
    via the target: sysroot, so it tries closing them.  GDBserver is
    tearing down already, so remote communication breaks down and we close
    the remote target and throw TARGET_CLOSE_ERROR.

    Note frame #14:

     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573

    That's a dtor, thus noexcept.  That's the reason for the
    std::terminate.

    Stepping back a bit, why do we still have open remote files if we've
    managed to detach already, and, we're debugging with "target remote"?
    The reason is that commit 408f66864a1a823591b26420410c982174c239a2
    makes detach_command hold a reference to the target, so the remote
    target won't be finally closed until frame #28 returns.  It's closing
    the target that invalidates target file I/O handles.

    This commit fixes the issue by not relying on target_close to
    invalidate the target file I/O handles, instead invalidate them
    immediately in remote_unpush_target.  So when GDB purges the solibs,
    and we end up in target_fileio_close (frame #7 above), there's nothing
    to do, and we don't try to talk with the remote target anymore.

    The regression isn't seen when testing with
    --target_board=native-gdbserver, because that does "set sysroot" to
    disable the "target:" sysroot, for test run speed reasons.  So this
    commit adds a testcase that explicitly tests detach with "set sysroot
    target:".

    gdb/ChangeLog:
    yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

            PR gdb/28080
            * remote.c (remote_unpush_target): Invalidate file I/O target
            handles.
            * target.c (fileio_handles_invalidate_target): Make extern.
            * target.h (fileio_handles_invalidate_target): Declare.

    gdb/testsuite/ChangeLog:
    yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

            PR gdb/28080
            * gdb.base/detach-sysroot-target.exp: New.
            * gdb.base/detach-sysroot-target.c: New.

    Reported-By: Jonah Graham <jonah@kichwacoders.com>

    Change-Id: I851234910172f42a1b30e731161376c344d2727d

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
                   ` (4 preceding siblings ...)
  2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
@ 2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
  2021-07-13 14:37 ` pedro at palves dot net
  2021-07-13 14:38 ` pedro at palves dot net
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-13 14:35 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-11-branch branch has been updated by Pedro Alves
<palves@sourceware.org>:

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

commit 3e0910a5f00a5ac9636d54fe9bd216ccac393c99
Author: Pedro Alves <pedro@palves.net>
Date:   Mon Jul 12 18:03:22 2021 +0100

    Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)

    Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
    like this:

     (gdb) detach
     Detaching from program: target:/any/program, process 3671843
     Detaching from process 3671843
     Ending remote debugging.
     [Inferior 1 (process 3671843) detached]
     In main
     terminate called after throwing an instance of 'gdb_exception_error'
     Aborted (core dumped)

    Here's the exception above being thrown:

     (top-gdb) bt
     #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote
connection closed") at src/gdbsupport/common-exceptions.cc:222
     #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040,
timeout=10000) at src/gdb/remote.c:9440
     #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1
(this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0,
is_notif=0x0) at src/gdb/remote.c:9928
     #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040,
buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
     #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command
(this=0x555556a11040, command_bytes=13, which_packet=14,
remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at
src/gdb/remote.c:12137
     #5  0x0000555555bc1b6c in remote_target::remote_hostio_close
(this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12455
     #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol
reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
     this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at
src/gdb/remote.c:12462
     #7  0x0000555555c9274c in target_fileio_close (fd=3,
target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
     #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0,
stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
     #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:599
     #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:847
     #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at
src/bfd/opncls.c:814
     #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:626
     #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at
src/gdb/gdb_bfd.c:715
     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573
     #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at
/usr/include/c++/9/bits/shared_ptr_base.h:377
     #16 0x000055555572b7c8 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
     #17 0x00005555557263c3 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x555556bf0588, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr_base.h:730
     #18 0x0000555555ae745e in std::__shared_ptr<objfile,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580,
__in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
     #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr
(this=0x555556bf0580, __in_chrg=<optimized out>) at
/usr/include/c++/9/bits/shared_ptr.h:103
     #20 0x0000555555b1c1dc in
__gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> >
>::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580)
at /usr/include/c++/9/ext/new_allocator.h:153
     #21 0x0000555555b1bb1d in
std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> >
> >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at
/usr/include/c++/9/bits/alloc_traits.h:497
     #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
     #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>,
std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60,
__position=std::shared_ptr<objfile> (expired, weak count 1) = {get() =
0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
     #24 0x0000555555b19576 in program_space::remove_objfile
(this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
     #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at
src/gdb/objfiles.c:487
     #26 0x0000555555ae5a12 in objfile_purge_solibs () at
src/gdb/objfiles.c:875
     #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at
src/gdb/solib.c:1236
     #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at
src/gdb/infcmd.c:2769

    Note frame #14:

     #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540,
__in_chrg=<optimized out>) at src/gdb/objfiles.c:573

    That's a dtor, thus noexcept.  That's the reason for the
    std::terminate.

    The previous patch fixed things such that the exception above isn't
    thrown anymore.  However, it's possible that e.g., the remote
    connection drops just while a user types "nosharedlibrary", or some
    other reason that leads to objfile::~objfile, and then we end up the
    same std::terminate problem.

    Also notice that frames #9-#11 are BFD frames:

     #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at
src/bfd/opncls.c:599
     #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at
src/bfd/opncls.c:847
     #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at
src/bfd/opncls.c:814

    BFD is written in C and thus throwing exceptions over such frames may
    either not clean up properly, or, may abort if bfd is not compiled
    with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
    all GCC ports do).

    Thus frame #8 seems like a good place to swallow exceptions.  More so
    since in this spot we already ignore target_fileio_close return
    errors.  That's what this commit does.  Without the previous fix, we'd
    see:

     (gdb) detach
     Detaching from program: target:/any/program, process 2197701
     Ending remote debugging.
     [Inferior 1 (process 2197701) detached]
     warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote
connection closed

    Note it prints a warning, which would still be a regression compared
    to GDB 10, if it weren't for the previous fix.

    gdb/ChangeLog:
    yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

            PR gdb/28080
            * gdb_bfd.c (gdb_bfd_close_warning): New.
            (gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
            try/catch and print warning on exception.
            (gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.

    Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
                   ` (5 preceding siblings ...)
  2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
@ 2021-07-13 14:37 ` pedro at palves dot net
  2021-07-13 14:38 ` pedro at palves dot net
  7 siblings, 0 replies; 9+ messages in thread
From: pedro at palves dot net @ 2021-07-13 14:37 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

--- Comment #6 from Pedro Alves <pedro at palves dot net> ---
Fixed, gdb 11 and master.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug gdb/28080] detach causes core dump
  2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
                   ` (6 preceding siblings ...)
  2021-07-13 14:37 ` pedro at palves dot net
@ 2021-07-13 14:38 ` pedro at palves dot net
  7 siblings, 0 replies; 9+ messages in thread
From: pedro at palves dot net @ 2021-07-13 14:38 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28080

Pedro Alves <pedro at palves dot net> changed:

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

--- Comment #7 from Pedro Alves <pedro at palves dot net> ---
Closing.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-07-13 14:38 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-12 15:33 [Bug gdb/28080] New: detach causes core dump jonah at kichwacoders dot com
2021-07-12 16:05 ` [Bug gdb/28080] " simark at simark dot ca
2021-07-12 19:37 ` pedro at palves dot net
2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
2021-07-13 14:32 ` cvs-commit at gcc dot gnu.org
2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
2021-07-13 14:35 ` cvs-commit at gcc dot gnu.org
2021-07-13 14:37 ` pedro at palves dot net
2021-07-13 14:38 ` pedro at palves dot net

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).