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

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

[torbjorn.svensson at st dot com]

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

            Bug ID: 29538
           Summary: Running "info threads" multiple times produce
                    different output when target has been halted the
                    entire time
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: torbjorn.svensson at st dot com
  Target Milestone: ---

Created attachment 14303
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14303&action=edit
GDB output with "set debug remote 1"

When using 27d582267a1d06e94661979f8893799ac235a768 (master as of this writing)
with SEGGER J-Link GDB server (with FreeRTOS support enabled) causes GDB to
believe that there are 2 threads when there in fact is only one, but the thread
changed id.

The board used is a STM3240G-EVAL board, but I'm sure the same thing can be
reproduced on a native GDB server with some tweaking of the RSP replies.

The SEGGER J-Link GDB server (version 7.70c) is launched using this command:
./JLinkGDBServerCLExe -port 2331 -s -device STM32F407IG -endian little -speed
4000 -if swd -vd -rtos GDBServer/RTOSPlugin_FreeRTOS.so


The GDB client is launched using this command:
arm-none-eabi-gdb -x /tmp/segger/commands

The content of /tmp/segger/commands is:
set debug threads 1
set target-async on
file /tmp/segger/40g-eval.elf
target remote :2331
p "info1"
info threads
p "thread1"
thread
p "info2"
info threads
p "thread2"
thread
monitor reset
break main
continue
quit



The output from GDB is:
GNU gdb (GDB) 13.0.50.20220829-git
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Warning: 'set target-async', an alias for the command 'set mi-async', is
deprecated.
Use 'set mi-async'.

[threads] add_thread_silent: add thread to inferior 1, ptid 42000.57005.0,
target remote
[threads] new_thread: creating a new thread object, inferior 1, ptid
42000.57005.0
Reset_Handler () at ../Core/Startup/startup_stm32f407ighx.s:63
63      ../Core/Startup/startup_stm32f407ighx.s: No such file or directory.
$1 = "info1"
[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]
  Id   Target Id         Frame
* 1    Thread 57005      Reset_Handler () at
../Core/Startup/startup_stm32f407ighx.s:63
  2    Remote target     Reset_Handler () at
../Core/Startup/startup_stm32f407ighx.s:63
$2 = "thread1"
[Current thread is 1 (Thread 57005)]
$3 = "info2"
[threads] delete_thread_1: deleting thread 42000.57005.0, silent = 0
  Id   Target Id         Frame
  2    Remote target     Reset_Handler () at
../Core/Startup/startup_stm32f407ighx.s:63

The current thread <Thread ID 1> has terminated.  See `help thread'.
$4 = "thread2"
[Current thread is 1 (Thread 57005) (exited)]
Resetting target
Breakpoint 1 at 0x80004d8: file ../Core/Src/main.c, line 118.
/tmp/segger/commands:22: Error in sourced command file:
Cannot execute this command without a live selected thread.


On line 22 in /tmp/segger/commands, the command is "continue".

As can be seen, the "continue" command fails due to that GDB gets confused by
the number of threads.

Looking at the RSP log(attached due to that bugzilla thought it was spam), I
can see a few things that might be the root cause of the problem.
1. Why is the thread list requested prior to running the qSymbols dance? If
it's delayed until after the qSymbols, then the "0000dead" would likely never
be received by the GDB client.
2. It looks like a new thread is detected on the 1st "info threads", but the
old thread is removed on the 2nd "info threads". I suppose both the removal and
the creation should be done in the 1st "info threads", or even better, just
update the id of the remote thread.
Is there any reason to remove thread 1 and create thread 2 when GDB thought
there was one thread and after the qfThreadInfo RSP-command, there is still
only one thread, but with different id?
3. The thread id "00000000" is a bad id, but overriding the RSP response with
another id, like "42", does not help either. The bad usage of thread id "0" has
been reported to SEGGER and hopefully, they will change this in a future
version of their software.

The problems above has been seen with various released versions of GDB too, so
it's not a regression. It's also present in all-stop mode. I've not checked if
the same problem is visible in non-stop mode and SEGGER J-Link GDB server does
not support non-stop mode.

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

[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]

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.