public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Subject: [binutils-gdb] [LynxOS] GDBserver crash debugging threaded program Date: Mon, 23 Nov 2015 18:24:00 -0000 [thread overview] Message-ID: <80d82c196402f6a61aa84452104b9aaed364eb42@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 80d82c196402f6a61aa84452104b9aaed364eb42 *** Author: Joel Brobecker <brobecker@adacore.com> Branch: master Commit: 80d82c196402f6a61aa84452104b9aaed364eb42 [LynxOS] GDBserver crash debugging threaded program This crash is observable by debugging a threaded program on LynxOS. On the GDB side, this is what we would see: % gdb q (gdb) target remote machine:4444 (gdb) break q.adb:6 (gdb) cont [gdb hits breakpoint] (gdb) cont Remote connection closed <<<--- expected: [Inferior 1 (Remote target) exited normally] On the gdbserver side, which was launched as usual: % gdbserver --once :4444 q Segmentation fault (core dumped) Ooops! The problem happens while GDB is trying to handle the thread termination event of the thread that hit the breakpoint. It started happening after the following change was made: commit 96e7a1eb6d09fda9e22e112e35e7d0085a8f4fd0 Date: Fri Oct 16 11:08:38 2015 -0400 Subject: gdbserver: Reset current_thread when the thread is removed. Reset current_thread and make sure 'remove_process' is used after all associated threads have been removed first. More precisely: . GDBserver receives the execution-resume order; . lynx-low resumes it succesfully, and then relies on lynx_wait_1 to wait for the next event; . We quickly receive one, which lynx_wait_1 analyzes to be a "thread exit" event, and therefore does... case SIGTHREADEXIT: remove_thread (find_thread_ptid (new_ptid)); lynx_continue (new_ptid); goto retry; => remove_thread causes current_thread to be set to NULL... (that's the recent change mentioned above) => ... which causes problems during lynx_continue, because it calls lynx_resume, which calls regcache_invalidate, which unfortunately assumes that CURRENT_THREAD is not NULL: void regcache_invalidate (void) { /* Only update the threads of the current process. */ SEGV!--> int pid = ptid_get_pid (current_thread->entry.id); find_inferior (&all_threads, regcache_invalidate_one, &pid); } Since the problem at hand is caused by trying to figure out which inferior to reset the regcache for, and since lynx_resume actually had that info, this patch fixes the problem by introducing a new routine called regcache_invalidate_pid, which invalidates the cache of the given pid; and then modifies lynx_resume use that new routine rather than relying on regcache_invalidate to invalidate the regcache of the expected inferior. gdb/gdbserver/ChangeLog: * regcache.h (regcache_invalidate_pid): Add declaration. * regcache.c (regcache_invalidate_pid): New function, extracted from regcache_invalidate. (regcache_invalidate): Reimplement using regcache_invalidate_pid. Add trivial documentation comment. * lynx-low.c: Use regcache_invalidate_pid instead of regcache_invalidate.
next reply other threads:[~2015-11-23 18:24 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-23 18:24 sergiodj+buildbot [this message] 2015-11-23 18:26 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot 2015-11-23 19:40 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot 2015-11-23 19:50 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot 2015-11-23 20:19 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot 2015-11-23 21:13 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot 2015-11-23 21:48 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot 2015-11-23 21:54 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2015-11-23 22:06 ` Failures on Debian-i686, " sergiodj+buildbot 2015-11-23 22:06 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot 2015-11-23 22:24 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2015-11-23 22:37 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot 2015-11-23 22:50 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot 2015-11-23 23:05 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot 2015-11-23 23:42 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj+buildbot 2015-11-23 23:58 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot 2015-11-24 1:23 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot 2015-11-24 2:03 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " 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=80d82c196402f6a61aa84452104b9aaed364eb42@gdb-build \ --to=sergiodj+buildbot@redhat.com \ --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).