[RFC] fix thread.c assertion after stepping past end of program

[RFC] fix thread.c assertion after stepping past end of program

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

We've run into an assertion failure when quitting GDB after stepping 
past the end of a program that was linked with stripped libraries. 
Here's how it's triggered, using a simple factorial example for 
nios2-linux-gnu target with gdbserver:

Breakpoint 1, main () at /home/sandra/examples/fact.c:13
13        for (i = 0; i < 10; ++i) {
(gdb) advance 17
main () at /home/sandra/examples/fact.c:17
17        return 0;
(gdb) s
18      }
(gdb) s
0x2aaefffc in __libc_start_main ()
    from 
/./scratch/sandra/nios2-linux-spring-release/install/opt/codesourcery/nios2-linux-gnu/libc//lib/libc.so.6
(gdb) s
Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 15772) exited normally]
You can't do that without a process to debug.
(gdb) s
The program is not being run.
(gdb) quit
/scratch/sandra/nios2-linux-fsf/obj/gdb-src-mainline-0-nios2-linux-gnu-x86_64-linux-gnu/gdb/inferior.c:287: 
internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' 
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

The attached 1-liner patch fixes it and didn't cause regressions 
elsewhere.  However, I'm not sure if this is really where the bug is. 
Maybe some other state is not getting cleaned out when the inferior 
exits?  WDYT?

-Sandra

[-- Attachment #2: thread.patch --]
[-- Type: text/x-patch, Size: 483 bytes --]

diff --git a/gdb/thread.c b/gdb/thread.c
index 91741c7..c44b2b0 100644
--- a/gdb/thread.c
+++ b/gdb/thread.c
@@ -628,8 +628,8 @@ any_thread_of_inferior (inferior *inf)
 {
   gdb_assert (inf->pid != 0);
 
-  /* Prefer the current thread.  */
-  if (inf == current_inferior ())
+  /* Prefer the current thread, if there is one.  */
+  if (inf == current_inferior () && inferior_ptid != null_ptid)
     return inferior_thread ();
 
   for (thread_info *tp : inf->non_exited_threads ())

Re: [RFC] fix thread.c assertion after stepping past end of program

[Sandra Loosemore]

On 4/30/19 9:33 AM, Sandra Loosemore wrote:
> We've run into an assertion failure when quitting GDB after stepping 
> past the end of a program that was linked with stripped libraries. 
> Here's how it's triggered, using a simple factorial example for 
> nios2-linux-gnu target with gdbserver:
> 
> Breakpoint 1, main () at /home/sandra/examples/fact.c:13
> 13        for (i = 0; i < 10; ++i) {
> (gdb) advance 17
> main () at /home/sandra/examples/fact.c:17
> 17        return 0;
> (gdb) s
> 18      }
> (gdb) s
> 0x2aaefffc in __libc_start_main ()
>     from 
> /./scratch/sandra/nios2-linux-spring-release/install/opt/codesourcery/nios2-linux-gnu/libc//lib/libc.so.6 
> 
> (gdb) s
> Single stepping until exit from function __libc_start_main,
> which has no line number information.
> [Inferior 1 (process 15772) exited normally]
> You can't do that without a process to debug.
> (gdb) s
> The program is not being run.
> (gdb) quit
> /scratch/sandra/nios2-linux-fsf/obj/gdb-src-mainline-0-nios2-linux-gnu-x86_64-linux-gnu/gdb/inferior.c:287: 
> internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' 
> failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n)
> 
> The attached 1-liner patch fixes it and didn't cause regressions 
> elsewhere.  However, I'm not sure if this is really where the bug is. 
> Maybe some other state is not getting cleaned out when the inferior 
> exits?  WDYT?

Looking at this a little further, it seems that the 
TARGET_WAITKIND_EXITED case in handle_inferior_event_1 (in infrun.c) is 
not zeroing inf->pid as exit_inferior_1 (in inferior.c) does.  If it did 
that, kill_or_detach (in top.c) would know the inferior is already dead 
and not call any_thread_of_inferior on it at all.  But, maybe it is not 
supposed to be completely dead at that point yet?  I'm not familiar 
enough with this code to know what the correct expectations are.  :-S

-Sandra