This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] GDBserver crashes when killing a multi-thread process
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Tue, 14 Jul 2015 09:00:39 +0100
- Subject: Re: [PATCH v2] GDBserver crashes when killing a multi-thread process
- Authentication-results: sourceware.org; auth=none
- References: <510f2362-8d33-4c3c-9a13-5d187f26abdf at SVR-ORW-FEM-04 dot mgc dot mentorg dot com> <53AF87EB dot 60703 at mentor dot com> <53B3CBDB dot 5030207 at redhat dot com> <53BEAE5E dot 7030209 at redhat dot com> <55A3E23C dot 8020101 at gmail dot com> <55A3F626 dot 7050409 at redhat dot com>
Pedro Alves <palves@redhat.com> writes:
> Looks like I forgot to push the rest of that series:
>
> https://sourceware.org/ml/gdb-patches/2015-03/msg00182.html
>
> What do you think of that one?
Yes, it looks good to me. We also need it on 7.10 branch.
>
>> Why don't we implement kill_wait_lwp like its counterpart in GDB
>> linux-nat.c:kill_wait_callback? we can loop and assert like this
>> patch below, (note that this patch fixes the internal error, and
>> the FAIL is still there).
>>
>
> Seems to me it's not 100% correct to waitpid the pid one more time
> after we've already reaped it, because there's a minuscule chance
> another process that we're debugging could clone a new lwp that reuses
> the PID of the one we've just killed/reaped, and then another iteration
> could collect the initial SIGSTOP of the wrong LWP and we'd kill it:
>
> -> kill (pid1, SIGKILL);
> <- waitpid (pid1) returns pid1/WSIGNALLED
> -> on iteration1: new pid1 clone lwp is spawned
> -> ret==pid1, continue iterating
> -> kill (pid1, SIGKILL); // killing wrong process
> <- waitpid (pid1) returns either SIGSTOP or WSIGNALLED
> ...
Yes, that is possible.
--
Yao (éå)