Re: [RFA/gdbserver] Unexpected EOF read from socket after inferior exits.

[Thomas Schwinge <thomas@codesourcery.com>]

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

Hello!

This has been seen in a mips64el-linux-gnu configuration while the GDB /
gdbserver testsuite is working on the gdb.threads/current-lwp-dead test.

On 2010-07-20 21:13, I wrote:
>     Running /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/testsuite/gdb.threads/current-lwp-dead.exp ...
>     [...]
>     > 'LD_LIBRARY_PATH=[...] [ld.so] [gdbserver] ':2887' 'current-lwp-dead'
>     Process current-lwp-dead created; pid = 20009
>     Listening on port 2887
>     target remote philidor:2887
>     Remote debugging using philidor:2887
>     Remote debugging from host 10.0.0.218
>     [...]
>     Breakpoint 2, fn_return (unused=0x0) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/testsuite/gdb.threads/current-lwp-dead.c:45
>     45        return 0;     /* at-fn_return */
>     (gdb) PASS: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return
>     testcase /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/testsuite/gdb.threads/current-lwp-dead.exp completed in 2 seconds
>     Running /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/testsuite/gdb.threads/execl.exp ...
>
> Here this test has finished, the remote gdbserver terminates, and the
> next test is about to be started.
>
>     Executing on host: mips64el-linux-gnu-gcc /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/testsuite/gdb.threads/execl.c  [...]
>     Killing all inferiors
>     Segmentation fault
>
> Instead of terminating, the remote gdbserver crashed with a segfault.
>
>     (gdb) bt
>     #0  0x1003b068 in thread_db_mourn (proc=0x0) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/thread-db.c:889
>     #1  0x1002bc3c in linux_mourn (process=0x0) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/linux-low.c:896
>     #2  0x1001085c in handle_v_cont (own_buf=0x555800d0 "W00") at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/server.c:1785
>     #3  0x10011154 in handle_v_requests (own_buf=0x555800d0 "W00", packet_len=7, new_packet_len=0x7faf0d64)
>         at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/server.c:1976
>     #4  0x100148e8 in process_serial_event () at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/server.c:3048
>     #5  0x10014a9c in handle_serial_event (err=0, client_data=0x0) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/server.c:3093
>     #6  0x1001bd70 in handle_file_event (event_file_desc=4) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/event-loop.c:488
>     #7  0x1001b134 in process_event () at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/event-loop.c:244
>     #8  0x1001c2e0 in start_event_loop () at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/event-loop.c:606
>     #9  0x1001303c in main (argc=3, argv=0x7faf1040) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/server.c:2589

> [...]
>     (gdb) frame 1
>     #1  0x1002bc3c in linux_mourn (process=0x0) at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/linux-low.c:896
>     896       thread_db_mourn (process);
>     (gdb) list
>     891     linux_mourn (struct process_info *process)
>     892     {
>     893       struct process_info_private *priv;
>     894
>     895     #ifdef USE_THREAD_DB
>     896       thread_db_mourn (process);
>     897     #endif
>     898
>     899       find_inferior (&all_lwps, delete_lwp_callback, process);
>     900
>     (gdb) frame 2
>     #2  0x1001085c in handle_v_cont (own_buf=0x555800d0 "W00") at /scratch/thomas/issue8927-FM_mips64el-linux-gnu/src/gdb-mainline/gdb/gdbserver/server.c:1785
>     1785            mourn_inferior (find_process_pid (ptid_get_pid (last_ptid)));
>     (gdb) list
>     1780          prepare_resume_reply (own_buf, last_ptid, &last_status);
>     1781          disable_async_io ();
>     1782
>     1783          if (last_status.kind == TARGET_WAITKIND_EXITED
>     1784              || last_status.kind == TARGET_WAITKIND_SIGNALLED)
>     1785            mourn_inferior (find_process_pid (ptid_get_pid (last_ptid)));
>     1786        }
>     1787      return;
>     1788
>     1789    err:
>
> So, the find_process_pid thing returns 0 where gdbserver doesn't expect
> it to do so.

Pedro helped me with that one.  It turns out that the problem is that in
this test constellation, the last LWP that exits is not the main LWP, but
both GDB and gdbserver are expecting the target backend to return the
main thread group id of the process that exited, and not the ID of the
last LWP that exited.

Here is a tested patch for gdbserver; OK to check in?  Might something
similar be needed for GDB itself?  I had a quick look, but couldn't spot
an equivalent problem.

2010-08-11  Thomas Schwinge  <thomas@codesourcery.com>

	* linux-low.c (linux_wait_1): Correctly return the ptid of the child
	after its termination.

Index: gdb/gdbserver/linux-low.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/linux-low.c,v
retrieving revision 1.152
diff -u -p -U10 -r1.152 linux-low.c
--- gdb/gdbserver/linux-low.c	9 Aug 2010 14:59:23 -0000	1.152
+++ gdb/gdbserver/linux-low.c	11 Aug 2010 12:10:53 -0000
@@ -2038,21 +2038,21 @@ retry:
 	  else
 	    {
 	      ourstatus->kind = TARGET_WAITKIND_SIGNALLED;
 	      ourstatus->value.sig = target_signal_from_host (WTERMSIG (w));
 
 	      if (debug_threads)
 		fprintf (stderr, "\nChild terminated with signal = %x \n", WTERMSIG (w));
 
 	    }
 
-	  return pid_to_ptid (pid);
+	  return ptid_of (event_child);
 	}
     }
   else
     {
       if (!WIFSTOPPED (w))
 	goto retry;
     }
 
   /* If this event was not handled before, and is not a SIGTRAP, we
      report it.  SIGILL and SIGSEGV are also treated as traps in case


Regards,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]