This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 00/23] All-stop on top of non-stop
- From: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>, Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 20 Apr 2015 17:18:24 +0100
- Subject: Re: [PATCH v3 00/23] All-stop on top of non-stop
- Authentication-results: sourceware.org; auth=none
- References: <1429267521-21047-1-git-send-email-palves at redhat dot com> <5534EADB dot 2040201 at gmail dot com> <87bniirdxf dot fsf 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