Re: [PATCH v3 00/23] All-stop on top of non-stop

[Pedro Alves <palves at redhat dot com>]

On 04/20/2015 04:56 PM, Sergio Durigan Junior wrote:
> On Monday, April 20 2015, Yao Qi wrote:
> 
>> Hi Pedro,
>> I tested V3 on arm GNU/Linux and aarch64 GNU/Linux in both native and
>> gdbserver, there is no regression on arm GNU/Linux.  

Thanks!  That's great news.

>> There is one
>> regression on aarch64 GNU/Linux native, but I don't see how is this fail
>> related to your V3 patches.  

I assume you mean you saw this once, and if that if you rerun that
test in particular, the fail goes away.

> Note that there is no regression either on
>> aarch64 GNU/Linux with gdbserver.

Awesome.

>>
>>  (gdb) info threads^M
>>  Id   Target Id         Frame ^M
>>  ...
>>    30   Thread 0x2019dff1f0 (LWP 28308) "joinable" 0x0000002000121a68
>> in clone () from /lib/aarch64-linux-gnu/libc.so.6^
>>  ...
>>  GPT: lwp Thread 0x2019dff1f0 (LWP 28308) has no pending signal^M
>>  Can't detach Thread 0x2019dff1f0 (LWP 28308): No such process^
>>  (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1:
>> detach
>>
>> Another race problem on attach/detach?

I think so, yes.  The same race that was fixed for regular
resumes, here:

  https://sourceware.org/ml/gdb-patches/2015-03/msg00597.html

can easily happen when detaching.  Say, you have 2 threads in your
program.  GDB must detach from each thread individually.  So it
starts by detaching from thread 1.  And just before detaching
from thread 2, thread 1 causes the whole process to exit.  So
the PTRACE_DETACH for thread 2 errors with ESRCH (No such process.)

Now I don't know is why you would see that on iteration 1 ("iter 1").
One possibility could be that a thread that has already been
detached crashed the process, because e.g., GDB left breakpoints
inserted in memory by mistake, or something is wrong with
infrun.c:prepare_for_detach, or something else along those lines.
In that case, assuming "ulimit -c unlimited", you'll probably find you have
a core dump for the crashing inferior.

> 
> FWIW, gdb.threads/attach-many-short-lived-threads.exp is one of the
> villains...  It always shows up on our BuildBot logs.

Yes, thought I don't think those have been showing a problem with the
test, but rather that the test is still catching bugs.

Thanks,
Pedro Alves