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

[Yao Qi <qiyaoltc@gmail.com>]

Pedro Alves <palves@redhat.com> writes:

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

No, I saw these fails very time I run this single test.

>
>> 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.

Thanks for the clue.  I'll dig it deeper.  I'll read these patches
today, if I don't see any new problems or questions, these patches are
fine to me.

-- 
Yao (齐尧)