[Bug gdb/29278] gdb crashes on interrupt (non-stop mode, target extended-remote)

[Bug gdb/29278] gdb crashes on interrupt (non-stop mode, target extended-remote)

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Product|binutils                    |gdb
          Component|binutils                    |gdb
            Version|unspecified                 |HEAD

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

[Bug gdb/29278] gdb crashes on interrupt (non-stop mode, target extended-remote)

[pedro at palves dot net]

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

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro at palves dot net

--- Comment #1 from Pedro Alves <pedro at palves dot net> ---
I don't think the comment is outdated.  

There's not enough info here to tell what went wrong, though.  

But try comparing with connecting in extended-remote to gdbserver.  You'll see
that "interrupt" doesn't crash in that scenario.  What is different?

shell 1
$ gdbserver --multi :9999

shell 2
$ gdb -ex "tar extended-remote :9999"
...
Remote debugging using :9999
(gdb) interrupt 
(gdb) 

I'd look at "set debug remote 1" in both scenarios for starters.

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

[Bug gdb/29278] gdb crashes on interrupt (non-stop mode, target extended-remote)

[pedro at palves dot net]

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

--- Comment #2 from Pedro Alves <pedro at palves dot net> ---
Whoops.  I had forgotten "set non-stop on".  If I do that before connecting to
gdbserver, it crashes too:

$ gdb -ex "set non-stop on" -ex "tar extended-remote :9999"
GNU gdb (GDB) 13.0.50.20220620-git
...
Remote debugging using :9999
(gdb) interrupt 
../../src/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid
!= 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

The bug is in interrupt_target_1, which does:

  if (non_stop)
    {
      if (all_threads)
        {
          scoped_restore_current_thread restore_thread;

          for (inferior *inf : all_inferiors ())
            {
              switch_to_inferior_no_thread (inf);
              stop_current_target_threads_ns (minus_one_ptid);
            }
        }
      else
        stop_current_target_threads_ns (inferior_ptid); <<<<<


interrupt with no arguments means "stop current thread".  But there's no
current thread, inferior_ptid is null_ptid.

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

[Bug gdb/29278] gdb crashes on interrupt (non-stop mode, target extended-remote)

[Manfred.Steiner at gmx dot at]

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

--- Comment #3 from Manfred Steiner <Manfred.Steiner at gmx dot at> ---
There are some more similar problems:

1) start gdb (for target avr)
2) (gdb) set non-stop 1
3) (gdb) file ...
4) (gdb) target extended-remote ...

The stub returns no thread running (in my point of view OK for extended-remote
mode); means "$qfThreadInfo#bb" -> "$l#6c" in gdb protocol.

5) (gdb) load

gdb crashes
  ...
  .../binutils-gdb/gdb/thread.c:85
  ...
  .../binutils-gdb/gdb/symfile.c:1836 
  ...

because command load (symfile.c:1836) is not checking if inferior has threads.
In this case inferior has no threads, so current_thread is nullptr, and
function inferior_thread (thread.c:85) fails on gdb_assert (current_thread_ !=
nullptr);

Simple fix possible with additional check in load command:

add on binutils-gdb/gdb/symfile.c:1836: 
if (current_inferior()->ptid_thread_map.size() == 0) {
  error (_("Error: current inferior has no threads, cannot load"));
  return;
}

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