aboutsummaryrefslogtreecommitdiff
path: root/sim/sh64/aclocal.m4
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@adacore.com>2019-01-05 11:55:08 +0400
committerJoel Brobecker <brobecker@adacore.com>2019-01-05 11:55:08 +0400
commit2eab46b176fa315ebc07569280f020c3348c2aa2 (patch)
tree67d0608d48987876be39ff098ce42a26601e43e5 /sim/sh64/aclocal.m4
parent2ee73c7abf6408c543bf297271c83dff8e87ee44 (diff)
downloadgdb-2eab46b176fa315ebc07569280f020c3348c2aa2.zip
gdb-2eab46b176fa315ebc07569280f020c3348c2aa2.tar.gz
gdb-2eab46b176fa315ebc07569280f020c3348c2aa2.tar.bz2
GDB crash re-running program on Windows (native)
Running any program twice on Windows current results in GDB crashing: $ gdb -q any_program (gdb) run $ gdb dummy -batch -ex run -ex run [New Thread 684960.0xe5878] [New Thread 684960.0xd75ac] [New Thread 684960.0xddac8] [New Thread 684960.0xc1f50] [Thread 684960.0xd75ac exited with code 0] [Thread 684960.0xddac8 exited with code 0] [Thread 684960.0xc1f50 exited with code 0] [Inferior 1 (process 684960) exited normally] (gdb) run Segmentation fault The crash happens while processing the CREATE_PROCESS_DEBUG_EVENT for the second run; in particular, we have in get_windows_debug_event: | case CREATE_PROCESS_DEBUG_EVENT: | [...] | if (main_thread_id) | windows_delete_thread (ptid_t (current_event.dwProcessId, 0, | main_thread_id), | 0); The problem is that main_thread_id is the TID of the main thread from the *previous* inferior, and this code is trying to delete that thread. The problem is that it is constructing a PTID by pairing the TID of the previous inferior with the PID of the new inferior. As a result, when we dig inside windows_delete_thread to see how it would handle that, we see... | delete_thread (find_thread_ptid (ptid)); Since the PTID is bogus, we end up calling delete_thread with a NULL thread_info. It used to be harmless, turning the delete_thread into a nop, but the following change... | commit 080363310650c93ad8e93018bcb6760ba5d32d1c | Date: Thu Nov 22 16:09:14 2018 +0000 | Subject: Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc. ... changed delete_thread to get the list of threads from the inferior, which itself is now accessed via the given thread_info. This is the corresponding diff that shows the change: | - for (tp = thread_list; tp; tpprev = tp, tp = tp->next) | + for (tp = thr->inf->thread_list; tp; tpprev = tp, tp = tp->next) As a result of this, passing a NULL thread_info is no longer an option! Stepping back a bit, the reason behind deleting the thread late could be found in a patch from Dec 2003, which laconically explains: | commit 87a45c96062d658ca83b50aa060a648bf5f5f1ff | Date: Fri Dec 26 00:39:04 2003 +0000 | | * win32-nat.c (get_child_debug_event): Keep main thread id around | even after thread exits since Windows insists on continuing to | report events against it. A look at the gdb-patches archives did not provide any additional clues (https://www.sourceware.org/ml/gdb-patches/2003-12/msg00478.html). It is not clear whether this is still needed or not. This patch assumes that whatever isue there was, the versions of Windows we currently support no longer have it. With that in mind, this commit fixes the issue by deleting the thread when the inferior sends the exit-process event as opposed to deleting it later, while starting a new inferior. This also restores the printing of the thread-exit notification for the main thread, which was missing before. Looking at the transcript of the example shown above, we can see 4 thread creation notifications, and only 3 notifications for thread exits. Now creation and exit notifications are balanced. In the handling of EXIT_THREAD_DEBUG_EVENT, the main_thread_id check is removed because deemed unnecessary: The main thread was introduced by a CREATE_PROCESS_DEBUG_EVENT, and thus the kernel is expected to report its death via EXIT_PROCESS_DEBUG_EVENT. And finally, because the behavior of delete_thread did change (albeit when getting a value we probably never expected to receive), this patch also adds a gdb_assert. The purpose is to provide some immediate information in case there are other callers that mistakenly call delete_thread with a NULL thread info. This can be useful information when direct debugging of GDB isn't an option. gdb/ChangeLog: * thread.c (delete_thread_1): Add gdb_assert that THR is not NULL. Initialize tpprev to NULL instead of assigning it to NULL on the next statement. * windows-nat.c (windows_delete_thread): Remove check for main_thread_id before printing thread exit notifications. (get_windows_debug_event) <EXIT_THREAD_DEBUG_EVENT>: Remove thread ID check against main_thread_id. <CREATE_PROCESS_DEBUG_EVENT>: Remove call to windows_delete_thread. <EXIT_PROCESS_DEBUG_EVENT>: Add call to windows_delete_thread.
Diffstat (limited to 'sim/sh64/aclocal.m4')
0 files changed, 0 insertions, 0 deletions