[Bug remote/29538] Running "info threads" multiple times produce different output when target has been halted the entire time

["luis.machado at arm dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29538

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-09-09
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |luis.machado at arm dot com

--- Comment #1 from Luis Machado <luis.machado at arm dot com> ---
Looking at the logs, it seems SEGGER's J-Link GDB server is at fault.

First it reports an existing thread value of 0xdead (57005), which GDB accepts
and adds to the list:

  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m0000dead
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l

GDB asks for the thread list one more time:

  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m0000dead
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l

Then GDB asks what is the current thread, and the remote replies empty:

  [remote] Sending packet: $qC#b4
  [remote] Packet received:
  [remote] start_remote_1: warning: couldn't determine remote current thread;
picking first in list.

Now GDB is free to select whatever thread it wants, but there is only one, so
it selects 0xdead (57005).

GDB attempts to list threads one more time, to which the remote replies with
thread 0x0:

[remote] Sending packet: $qfThreadInfo#bb
[remote] Packet received: m00000000
[remote] Sending packet: $qsThreadInfo#c8
[remote] Packet received: l
[threads] add_thread_silent: add thread to inferior 1, ptid 42000.0.0, target
remote
[threads] new_thread: creating a new thread object, inferior 1, ptid 42000.0.0
[New Remote target]

So GDB is confused. But it acknowledges that thread 0xdead (57005) is gone:

The current thread <Thread ID 1> has terminated.  See `help thread'.
$4 = "thread2"
[Current thread is 1 (Thread 57005) (exited)]

In the last error, I think GDB is still trying to hold on to the current thread
that has exited:

Cannot execute this command without a live selected thread.

I suppose you could switch threads and resume debugging from this point
onwards.

It seems SEGGER J-Link needs to report the current thread (even if it doesn't
exist yet) and stick to its number until a "real" thread shows up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.