Re: [PATCH] gdb: fix an issue with thread list corruption

[Simon Marchi <simark@simark.ca>]

On 5/7/26 3:36 AM, Metzger, Markus T wrote:
> And what happens without ASan?  Do we introduce yet another sporadically failing test?

Perhaps, but such is the nature of "use after free" bugs, and that's the
point of ASan, to make them fail predictably.  Some people (including
me) test with ASan enabled, so someone would certainly catch it.  In
2026 we can assume that ASan is a core component of testing the
software.

If a test is failing sporadically because of a real bug in GDB, then the
test is doing its job.  If a test fails sporadically but not because of
a real bug in GDB, then it's a bad test.

> If we only created two additional threads, we could vary which thread we're stepping
> in two different runs of the test program, which makes the test program fairly trivial.
> 
> We'd need to step from one pthread_create() to the next to guarantee the order in
> which GDB adds the threads.  As long as GDB adds them to either the front or the
> back of the thread list consistently, we would get the same order in the two runs,
> and by varying the thread we're stepping, we would cover both possible orders.

Not sure I understand, but if you have an idea to improve what I
propose, go for it.

> But we wouldn't be able to guarantee that the other thread exited at just the right
> moment, would we?  We try to mitigate that by repeating this 100 times, but this is
> just asking for the test to fail sporadically at a random iteration - or pass.

Like I explained in my previous message, I think that with the test I
propose, the thread doesn't have to exit in a very tiny window for the
test to catch the failure.  That's because when threads exit on the
remote target, GDB doesn't learn about it until the next thread list
update.  So the thread has to exit after GDB learned about the thread
(which is at the previous breakpoint hit I think), and before the next
"continue -a".  It's a big window, so it's almost guaranteed that it
will happen, since the thread is short-lived.  In my testing, it always
caught it at iteration 1.

I think that the crash could be observed with the linux-nat target, but
then the window would be much smaller.  With the linux-nat target, the
thread_info is deleted as soon as the thread exits (and linux-nat
processes the event).  So for the crash to be observed, the thread would
have to exit between the moment the safe iterator grabs a reference to
the thread_info and the moment it tries to use it, that is a small
window.

> We have too many such tests already.  They may indicate an actual problem, or maybe
> the test itself is broken or inherently non-deterministic.  What such tests definitely do is
> create noise when trying to test a completely unrelated patch, thus slowing down GDB
> development.

With your fix, the test shouldn't randomly fail.  If it does, then it
means there is a problem with the test or with GDB, which should be
fixed either way.  The solution to this is not to not have tests.

> To get this deterministic, one would need to mock the remote target to guarantee
> the ordering of thread exit and step completion events.  Something like gdbreplay,
> but with hand-written logs, which would need to be maintained whenever anything
> in the remote communication changes.  For more substantial changes to the remote
> communication, this could become a significant burden.

If you wanted to write a test using gdbreplay, I wouldn't be against it,
but I also think that the maintenance burden probably makes it not worth
it.  I think that gdbreplay is useful to mock a misbehaving remote, for
example.

I think that "live" debugging test still has value, because it tests
against a real system.  For example, perhaps that running this new test
on Windows will point out that something is broken in the Windows target
or the Windows gdbserver, who knows.

> And without additional tooling, like ASan, we still wouldn't be able to fail deterministically.

So we shouldn't ever write tests for use-after-free or buffer overflow
bugs?

Simon