Re: [PATCH][gdb] Fix hang after ext sigkill

[Simon Marchi <simark@simark.ca>]

On 2020-03-25 11:51 a.m., Tom de Vries wrote:
> On 25-03-2020 15:44, Simon Marchi wrote:
>> On 2020-03-25 6:29 a.m., Tom de Vries wrote:
>>> Here's the updated patch.
>> Thanks.  Some comments about the test:
>>
>> - Please add a comment at the top to describe briefly what this is testing.
>> - Please replace the infinite loops with bounded ones (e.g. for (i = 0; i < 300; i++)),
>>   so that the test program eventually exits if something goes wrong and it is allowed to run
>>   freely.
> Done.
> 
> Thanks,
> - Tom
> 
> 
> 
> 0001-gdb-Fix-hang-after-ext-sigkill.patch
> 
> [gdb] Fix hang after ext sigkill
> 
> Consider the test-case from this patch, compiled with pthread support:
> ...
> $ gcc src/gdb/testsuite/gdb.threads/hang-after-ext-sigkill.c -lpthread
> ...
> 
> After running, the program sleeps:
> ...
> $ gdb a.out
> Reading symbols from a.out...
> (gdb) r
> Starting program: /data/gdb_versions/devel/a.out
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [New Thread 0x7ffff77fe700 (LWP 22604)]
> ...
> 
> Until we interrupt it with a control-C:
> ...
> ^C
> Thread 1 "a.out" received signal SIGINT, Interrupt.
> 0x00007ffff78c50f0 in nanosleep () from /lib64/libc.so.6
> (gdb)
> ...
> 
> If we then kill the inferior using an external SIGKILL:
> ...
> (gdb) shell killall -s SIGKILL a.out
> ...
> and subsequently continue:
> ...
> (gdb) c
> Continuing.
> Couldn't get registers: No such process.
> Couldn't get registers: No such process.
> (gdb) Couldn't get registers: No such process.
> (gdb) Couldn't get registers: No such process.
> (gdb) Couldn't get registers: No such process.
> <repeat>
> ...
> gdb hangs repeating the same warning.  Typing control-C no longer helps,
> and we have to kill gdb.
> 
> This is a regression since commit 873657b9e8 "Preserve selected thread in
> all-stop w/ background execution".  The commit adds a
> scoped_restore_current_thread typed variable restore_thread to
> fetch_inferior_event, and the hang is caused by the constructor throwing an
> exception.
> 
> Fix this by catching the exception in the constructor.
> 
> Build and reg-tested on x86_64-linux.
> 
> gdb/ChangeLog:
> 
> 2020-02-24  Tom de Vries  <tdevries@suse.de>
> 
> 	PR gdb/25471
> 	* thread.c
> 	(scoped_restore_current_thread::scoped_restore_current_thread): Catch
> 	exception in get_frame_id.
> 
> gdb/testsuite/ChangeLog:
> 
> 2020-02-24  Tom de Vries  <tdevries@suse.de>
> 
> 	PR gdb/25471
> 	* gdb.threads/hang-after-ext-sigkill.c: New test.
> 	* gdb.threads/hang-after-ext-sigkill.exp: New file.
> 	* lib/gdb.exp (runto): Handle "Temporary breakpoint" string.

This is fine with me, but I'd prefer Pedro to take a look if he has time.  Given the current
situation, give him a few weeks, if you don't have any answers by then, then push it.

Simon