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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

Hello Simon,

>>> On 5/4/26 3:16 AM, Markus Metzger wrote:
>>>> When resuming a target in non-stop mode with 'c -a', the continue
>>> command
>>>> uses for_each_thread() to proceed each stopped thread individually.  This
>>>> uses an all_threads_safe() iteration.
>>>>
>>>> If one of the stopped threads does an inline step-over, since the target
>>>> is non-stop, we stop_all_threads(), which involves update_thread_list(),
>>>> which, in turn, may delete_thread().
>>>>
>>>> If this deleted the thread pointed to by the m_next safe iterator member,
>>>> the above all_threads_safe() iteration will be corrupted.
>>>>
>>>> The thread we're proceeding is stopped and there is no reason to delete
>>>> it.  Consequently, there is no reason for all_threads_safe(), which isn't
>>>> that safe in this scenario.
>>>>
>>>> Iterate using all_threads() and inline proceed_thread_callback().
>>>
>>> Just to try to make sure I understand the circumstances that lead the
>>> the failure correcty (and make sure this doesn't just cover up other
>>> problems):
>>>
>>> - thread 1 is stopped on a breakpoint
>>> - thread 2 is executing
>>> - displaced stepping is disabled
>>> - the target doesn't report thread events to the core
>>> - you "continue -a"
>>> - thread 1 starts an inline step-over, which calls stop_all_threads,
>>>   which calls update_thread_list
>>> - meanwhile, thread 2 exits
>>> - update_thread_list causes thread 2 to be deleted
>>> - the safe iterator's m_next field now points to a deleted thread info
>
>Can you comment on whether the sequence of events above sounds correct?
>If it is, I think it would be possible to write a CPU test to reproduce
>it, that would be helpful along with the fix.

The sequence sounds good, but I wonder how we would ensure that thread 2
exits just when we need it to.  This is non-stop mode, so we should learn about
the exit immediately.  The test would also need to rely on the ordering of threads
in the thread list.  And detecting the issue requires the next pointer of the next
element to be overwritten in a way that causes a deterministic effect - like crashing
GDB.  We wouldn't want to add another test that fails sporadically.

When looking at the safe-iterator code, it is obvious that it allows deleting the
current element and it does not allow deleting the next element.  So, nesting
safe-iterator iterations of the same list is a bad idea.

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928