From: Oleg Nesterov <oleg@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>,
Roland McGrath <roland@redhat.com>,
Tom Tromey <tromey@redhat.com>
Cc: archer@sourceware.org
Subject: Q: mutlithreaded tracees && clone/exit
Date: Fri, 16 Jul 2010 20:54:00 -0000 [thread overview]
Message-ID: <20100716205147.GA26313@redhat.com> (raw)
Hello.
In case this matters, I used gdb-7.1 for testing.
Q1: if gsbstub reported that the tracee has exited (say, we sent
'$X09#..' to gdb), can gsbstub assume it can forget about this thread?
I mean, can it assume that gdb won't send something like 'D;EXITED_PID'?
Or it should keep the info connected to the exited thread until the
explicit detach request? Or may be we should keep some info just to
report this exit code again to the next '$?#3f' request?
Looking at gdb sources/behaviour, I think the answer is yes, it can
forget. But I'd like to have the confirmation.
And. I'd like to let you know that gdb is buggy ;) But it is not very
easy to explain the bug because I don't know the terminology. Let's
consider this particular example:
(gdb) target extended-remote whatever
(gdb) attach PID
...
(gdb) c
Now gdb sleeps in sys_read/sys_recvfrom.
The user presses ^C, gdb sends 3 and waits for reply. Suppose that
gdbstub doesn't reply immediately.
The user presses ^C again and acks the "Give up (and stop debugging it)?"
question.
gdb does remote_close()->discard_all_inferiors()->...->exit_inferior_1().
Surprisingly, exit_inferior_1() does not remove this thread from
inferior_list but clears inf->pid.
This means that the subsequent find_inferior_pid() fails and returns NULL,
and gdb segfaults if the user does, say,
(gdb) detach
after that.
I noticed this bug when I found another problem, gdb+gdbserver doesn't
work correctly if the main thread exits. But let's forget about this
problem for now.
The main question is, I do not understand how gdbstub should handle the
multithreaded targets.
Trivial testcase:
void *tfunc(void *arg)
{
getchar();
return NULL;
}
int main(int argc, const char *argv[])
{
pthread_t thr;
printf("PID=%d\n", getpid());
pthread_create(&thr, NULL, tfunc, NULL);
for (;;)
pause();
return 0;
}
Gdbserver:
gdbserver --multi :2000
gdb:
(gdb) file test1
(gdb) target extended-remote :2000
(gdb) attach 16927
Attached to process 16927
...
0x00000033af60e57d in pause () from /lib64/libpthread.so.0
(gdb)
OK. gdbserver ptraces both threads. But afaics gdb doesn't now this
program is multithreaded, and strace shows that gdb doesn't send
qfThreadInfo request.
Q2: Shouldn't gdbstub let debugger know about sub-threads somehow?
Let'c continue:
(gdb) c
Continuing.
gdbserver resumes both threads. Press enter, the sub-thread exits.
And nothing happens! gdbserver sends nothing to gdb, it just reaps
the tracee silently:
rt_sigsuspend([]) = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigreturn(0x11) = -1 EINTR (Interrupted system call)
wait4(-1, 0x7fff2c719fbc, WNOHANG, NULL) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|__WCLONE, NULL) = 16928
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
wait4(-1, 0x7fff2c719fbc, WNOHANG, NULL) = 0
wait4(-1, 0x7fff2c719fbc, WNOHANG|__WCLONE, NULL) = -1 ECHILD (No child processes)
rt_sigsuspend([]
Q3: is it correct? shouldn't we inform the debugger?
So. Afaics, gdb can only find the new thread if the user does
"info threads", or if this thread reports somehow about itself
(say, it gets a signal and gdbserver sends "$T..." with its tid).
Also. gdb can't know the sub-thread has exited unless the user
does "info threads" again, or something like "$TpPID.TGID" gets
"E01" in reply.
Correct?
Q4: is this what we want to implement?
I am asking because that I thought that gdb+gdbserver should
try to work the same way as it works without gdbserver, and
thus it should see clone/exit.
However, gdbserver sends nothing to gdb if the tracee does
pthread_create() or pthread_exit().
Oleg.
next reply other threads:[~2010-07-16 20:54 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-16 20:54 Oleg Nesterov [this message]
2010-07-16 21:40 ` Roland McGrath
2010-07-18 17:51 ` Oleg Nesterov
2010-07-18 18:04 ` Oleg Nesterov
2010-07-18 20:22 ` Roland McGrath
2010-07-19 13:44 ` BUG: add_thread_silent()->switch_to_thread(minus_one_ptid) is wrong Oleg Nesterov
2010-07-19 15:36 ` Oleg Nesterov
2010-07-19 16:01 ` Q: mutlithreaded tracees && clone/exit Jan Kratochvil
2010-07-19 22:57 ` Roland McGrath
2010-07-20 13:18 ` Oleg Nesterov
2010-07-20 14:04 ` BUG? gdb, non-stop && c -a Oleg Nesterov
2010-07-20 14:12 ` Jan Kratochvil
2010-07-20 14:49 ` Oleg Nesterov
2010-07-20 15:08 ` Jan Kratochvil
2010-07-20 15:28 ` Oleg Nesterov
2010-07-20 19:43 ` Roland McGrath
2010-07-21 7:59 ` Oleg Nesterov
2010-07-21 8:10 ` Jan Kratochvil
2010-07-21 11:12 ` Oleg Nesterov
2010-07-20 14:21 ` Q: mutlithreaded tracees && clone/exit Jan Kratochvil
2010-07-20 15:09 ` Oleg Nesterov
2010-07-20 19:41 ` Roland McGrath
2010-07-21 8:32 ` Oleg Nesterov
2010-07-20 14:43 ` Q: who maintains the STOPPED/RUNNING state? Oleg Nesterov
[not found] ` <y0mk4ophmvn.fsf@fche.csb>
2010-07-21 10:20 ` Oleg Nesterov
2010-07-21 10:51 ` Oleg Nesterov
2010-07-21 17:06 ` Q: multiple inferiors, all-stop && vCont Oleg Nesterov
2010-07-21 20:42 ` Roland McGrath
2010-07-23 17:33 ` Oleg Nesterov
2010-07-26 14:30 ` Oleg Nesterov
2010-07-26 16:06 ` Oleg Nesterov
2010-07-28 18:19 ` gdbstub initial code, another approach Oleg Nesterov
2010-07-29 21:38 ` Frank Ch. Eigler
2010-07-30 13:00 ` Oleg Nesterov
2010-07-30 13:16 ` Frank Ch. Eigler
2010-07-30 15:01 ` Oleg Nesterov
2010-07-30 13:25 ` Jan Kratochvil
2010-07-30 14:44 ` Oleg Nesterov
2010-07-30 15:20 ` Jan Kratochvil
2010-08-02 12:54 ` Oleg Nesterov
2010-08-03 13:55 ` Jan Kratochvil
2010-07-30 17:59 ` Tom Tromey
2010-08-02 18:25 ` Oleg Nesterov
2010-08-02 23:54 ` Jan Kratochvil
2010-08-03 12:27 ` Q: %Stop && gdb crash Oleg Nesterov
2010-08-03 13:17 ` Oleg Nesterov
2010-08-03 19:57 ` Kevin Buettner
2010-08-04 19:42 ` Oleg Nesterov
2010-08-04 23:32 ` Kevin Buettner
2010-08-05 18:24 ` Oleg Nesterov
2010-08-03 13:36 ` Jan Kratochvil
2010-08-03 15:09 ` Oleg Nesterov
2010-08-03 12:39 ` Q: multiple inferiors, all-stop && vCont Jan Kratochvil
2010-08-03 14:32 ` Oleg Nesterov
2010-08-03 15:55 ` Jan Kratochvil
2010-08-03 16:56 ` Oleg Nesterov
2010-08-03 18:37 ` Jan Kratochvil
2010-08-18 17:07 ` Jan Kratochvil
2010-08-18 19:22 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100716205147.GA26313@redhat.com \
--to=oleg@redhat.com \
--cc=archer@sourceware.org \
--cc=fche@redhat.com \
--cc=roland@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).