Fix normal_stop latent bug
authorPedro Alves <palves@redhat.com>
Thu, 7 Mar 2019 16:35:06 +0000 (16:35 +0000)
committerPedro Alves <palves@redhat.com>
Thu, 7 Mar 2019 16:35:06 +0000 (16:35 +0000)
TARGET_WAITKIND_NO_RESUMED doesn't have an associated event thread, so
we shouldn't be referring to inferior_thread() assuming it points to
one.

This was caught on the multi-target branch, where we always switch to
no-thread-selected whenever we start handling an event, exactly to
catch places that incorrectly use "inferior_ptid/inferior_thread()"
without switching to the right event thread / target.

Here, on the branch, we assert in inferior_thread() because
TARGET_WAITKIND_NO_RESUMED doesn't have an associated event thread, so
inferior_ptid is still null_ptid.

gdb/ChangeLog:
2019-03-07  Pedro Alves  <palves@redhat.com>

* infrun.c (normal_stop): Also check for
TARGET_WAITKIND_NO_RESUMED before referring to inferior_thread().

gdb/ChangeLog
gdb/infrun.c

index d3d6e5b..5614e78 100644 (file)
@@ -1,3 +1,8 @@
+2019-03-07  Pedro Alves  <palves@redhat.com>
+
+       * infrun.c (normal_stop): Also check for
+       TARGET_WAITKIND_NO_RESUMED before referring to inferior_thread().
+
 2019-03-07  Andrew Burgess  <andrew.burgess@embecosm.com>
 
        * f-lang.c (value_from_host_double): Moved to...
index 61467be..33e5d43 100644 (file)
@@ -8146,7 +8146,8 @@ normal_stop (void)
   if (target_has_execution)
     {
       if (last.kind != TARGET_WAITKIND_SIGNALLED
-         && last.kind != TARGET_WAITKIND_EXITED)
+         && last.kind != TARGET_WAITKIND_EXITED
+         && last.kind != TARGET_WAITKIND_NO_RESUMED)
        /* Delete the breakpoint we stopped at, if it wants to be deleted.
           Delete any breakpoint that is to be deleted at the next stop.  */
        breakpoint_auto_delete (inferior_thread ()->control.stop_bpstat);