Fix windows_nat_target::fake_create_process ptid
Checks
Context |
Check |
Description |
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Testing passed
|
Commit Message
While working on Windows non-stop mode, I managed to introduce a bug
that led to fake_create_process being called. That then resulted in
GDB crashes later on, because fake_create_process added a thread with
an incorrect ptid for this target. It is putting dwThreadId in the
tid field of the ptid instead of on the lwp field. This is fixed by
this patch.
I do however wonder why nobody has seen it this long. The
fake_create_process code was added for
https://sourceware.org/bugzilla/show_bug.cgi?id=8153 and Chris said
back then, in:
https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html
"If the main thread has exited, there is never any create process
notification when attaching to a process. That confuses all sorts of
things."
Unfortunately, nowhere was it stated which version of Windows was that
observed on. I don't see any missing CREATE_PROCESS_DEBUG_EVENT when
I try the reproducer from the bugzilla on Windows 10. I would have to
try on Windows XP (the oldest version of Windows we claim to support),
but I don't have such a machine handy. Do note however, that
GDBserver has never gotten an equivalent to fake_create_process. But
I'm not sure that is proof enough that we can yank that out from GDB,
as seemingly not many people use Windows gdbserver.
Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215
---
gdb/windows-nat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
base-commit: c05dd51122c2d654031b04e02ad0ea5b53ffe5e2
Comments
> From: Pedro Alves <pedro@palves.net>
> Date: Fri, 22 Mar 2024 19:30:30 +0000
>
> While working on Windows non-stop mode, I managed to introduce a bug
> that led to fake_create_process being called. That then resulted in
> GDB crashes later on, because fake_create_process added a thread with
> an incorrect ptid for this target. It is putting dwThreadId in the
> tid field of the ptid instead of on the lwp field. This is fixed by
> this patch.
>
> I do however wonder why nobody has seen it this long.
AFAIU, to actually see the bug, one would need to attach GDB to a
process whose main thread has exited, is that true? If so, I'm not
surprised this bug was not reported: it's unusual for the main thread
to exit without shutting down the process, and the need to attach to
such a process (as opposed to having it run from GDB to begin with)
makes that even more rare. And finally, not every bug is reported by
the first person who sees it the first time, right?
On 2024-03-23 06:39, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> Date: Fri, 22 Mar 2024 19:30:30 +0000
>>
>> While working on Windows non-stop mode, I managed to introduce a bug
>> that led to fake_create_process being called. That then resulted in
>> GDB crashes later on, because fake_create_process added a thread with
>> an incorrect ptid for this target. It is putting dwThreadId in the
>> tid field of the ptid instead of on the lwp field. This is fixed by
>> this patch.
>>
>> I do however wonder why nobody has seen it this long.
>
> AFAIU, to actually see the bug, one would need to attach GDB to a
> process whose main thread has exited, is that true? If so, I'm not
> surprised this bug was not reported: it's unusual for the main thread
> to exit without shutting down the process, and the need to attach to
> such a process (as opposed to having it run from GDB to begin with)
> makes that even more rare. And finally, not every bug is reported by
> the first person who sees it the first time, right?
Yes, that could be the reason. But it could also be because the brokenness with the
Windows debug API that Chris was seeing only happens on Windows versions we no
longer claim support for (i.e., earlier than Windows XP).
Anyhow, the patch is pretty obvious on its own, so I went ahead and merged it
without that blurb in the commit log, like below.
I also wrote a testcase that exercises the scenario in question. I'll post
that next.
Here's what I merged.
From ccf3148e3133f016a8e1484e85e5e4d8c271c4f0 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Fri, 22 Mar 2024 19:28:55 +0000
Subject: [PATCH] Fix windows_nat_target::fake_create_process ptid
While working on Windows non-stop mode, I managed to introduce a bug
that led to fake_create_process being called. That then resulted in
GDB crashes later on, because fake_create_process added a thread with
an incorrect ptid for this target. It is putting dwThreadId in the
tid field of the ptid instead of on the lwp field. This is fixed by
this patch.
Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215
---
gdb/windows-nat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index ee38b985efa..b123a66ef0f 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1371,8 +1371,8 @@ windows_nat_target::fake_create_process ()
throw_winerror_with_name (_("OpenProcess call failed"), err);
/* We can not debug anything in that case. */
}
- add_thread (ptid_t (windows_process.current_event.dwProcessId, 0,
- windows_process.current_event.dwThreadId),
+ add_thread (ptid_t (windows_process.current_event.dwProcessId,
+ windows_process.current_event.dwThreadId, 0),
windows_process.current_event.u.CreateThread.hThread,
windows_process.current_event.u.CreateThread.lpThreadLocalBase,
true /* main_thread_p */);
base-commit: f9ee45c3a95ac37cf1c3f4ac6be34b9a53e306f4
@@ -1365,8 +1365,8 @@ windows_nat_target::fake_create_process ()
throw_winerror_with_name (_("OpenProcess call failed"), err);
/* We can not debug anything in that case. */
}
- add_thread (ptid_t (windows_process.current_event.dwProcessId, 0,
- windows_process.current_event.dwThreadId),
+ add_thread (ptid_t (windows_process.current_event.dwProcessId,
+ windows_process.current_event.dwThreadId, 0),
windows_process.current_event.u.CreateThread.hThread,
windows_process.current_event.u.CreateThread.lpThreadLocalBase,
true /* main_thread_p */);