public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Subject: [binutils-gdb] File I/O file handles after target closes Date: Wed, 11 Apr 2018 11:23:00 -0000 [thread overview] Message-ID: <20db9c52a2073246a5c46a0274569e10b317866f@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 20db9c52a2073246a5c46a0274569e10b317866f *** Author: Pedro Alves <palves@redhat.com> Branch: master Commit: 20db9c52a2073246a5c46a0274569e10b317866f File I/O file handles after target closes A future patch will propose making the remote target's target_ops be heap-allocated (to make it possible to have multiple instances of remote targets, for multiple simultaneous connections), and will delete/destroy the remote target at target_close time. That change trips on a latent problem, though. File I/O handles remain open even after the target is gone, with a dangling pointer to a target that no longer exists. This results in GDB crashing when it calls the target_ops backend associated with the file handle: (gdb) Disconnect Ending remote debugging. * GDB crashes deferencing a dangling pointer Backtrace: #0 0x00007f79338570a0 in main_arena () at /lib64/libc.so.6 #1 0x0000000000858bfe in target_fileio_close(int, int*) (fd=1, target_errno=0x7ffe0499a4c8) at src/gdb/target.c:2980 #2 0x00000000007088bd in gdb_bfd_iovec_fileio_close(bfd*, void*) (abfd=0x1a631b0, stream=0x223c9d0) at src/gdb/gdb_bfd.c:353 #3 0x0000000000930906 in opncls_bclose (abfd=0x1a631b0) at src/bfd/opncls.c:528 #4 0x0000000000930cf9 in bfd_close_all_done (abfd=0x1a631b0) at src/bfd/opncls.c:768 #5 0x0000000000930cb3 in bfd_close (abfd=0x1a631b0) at src/bfd/opncls.c:735 #6 0x0000000000708dc5 in gdb_bfd_close_or_warn(bfd*) (abfd=0x1a631b0) at src/gdb/gdb_bfd.c:511 #7 0x00000000007091a2 in gdb_bfd_unref(bfd*) (abfd=0x1a631b0) at src/gdb/gdb_bfd.c:615 #8 0x000000000079ed8e in objfile::~objfile() (this=0x2154730, __in_chrg=<optimized out>) at src/gdb/objfiles.c:682 #9 0x000000000079fd1a in objfile_purge_solibs() () at src/gdb/objfiles.c:1065 #10 0x00000000008162ca in no_shared_libraries(char const*, int) (ignored=0x0, from_tty=1) at src/gdb/solib.c:1251 #11 0x000000000073b89b in disconnect_command(char const*, int) (args=0x0, from_tty=1) at src/gdb/infcmd.c:3035 This goes unnoticed in current master, because the current remote target's target_ops is never destroyed nowadays, so we end up calling: remote_hostio_close -> remote_hostio_send_command which gracefully fails with FILEIO_ENOSYS if remote_desc is NULL (because the target is closed). Fix this by invalidating a target's file I/O handles when the target is closed. With this change, remote_hostio_send_command no longer needs to handle the case of being called with a closed remote target, originally added here: <https://sourceware.org/ml/gdb-patches/2008-08/msg00359.html>. gdb/ChangeLog: 2018-04-11 Pedro Alves <palves@redhat.com> * target.c (fileio_fh_t::t): Add comment. (target_fileio_pwrite, target_fileio_pread, target_fileio_fstat) (target_fileio_close): Handle a NULL target. (invalidate_fileio_fh): New. (target_close): Call it. * remote.c (remote_hostio_send_command): No longer check whether remote_desc is open.
next reply other threads:[~2018-04-11 11:23 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-11 11:23 sergiodj+buildbot [this message] 2018-04-11 11:23 ` Failures on Fedora-s390x-m64, branch master sergiodj+buildbot 2018-04-11 11:49 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2018-04-11 11:51 ` Failures on RHEL-s390x-m64, " sergiodj+buildbot 2018-04-11 11:56 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot 2018-04-11 12:08 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-04-11 12:26 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot 2018-04-11 12:26 ` Failures on Fedora-i686, " sergiodj+buildbot 2018-04-11 12:31 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-w64-mingw32, branch master *** BREAKAGE *** sergiodj+buildbot 2018-04-11 12:44 ` Failures on Fedora-x86_64-native-gdbserver-m64, branch master sergiodj+buildbot 2018-04-11 12:45 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot 2018-04-11 13:49 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-04-11 14:35 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot 2018-04-11 15:21 ` Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20db9c52a2073246a5c46a0274569e10b317866f@gdb-build \ --to=sergiodj+buildbot@sergiodj.net \ --cc=gdb-testers@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).