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

Yao Qi
2015-04-21T07:48:09Z

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 (齐尧)