This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v8] Add pretty printers for the NPTL lock types
- From: Pedro Alves <palves at redhat dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>, Siddhesh Poyarekar <siddhesh at sourceware dot org>
- Cc: libc-alpha at sourceware dot org, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Thu, 23 Jun 2016 10:47:17 +0100
- Subject: Re: [PATCH v8] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <20160608153304 dot 12910-1-martin dot galvan at tallertechnologies dot com> <20160608153841 dot GA8366 at devel dot intra dot reserved-bit dot com> <CAOKbPbZCbrfM=FRq6e7C3c8uXp9v+BODAoh6Qat7XRwOb5cEHA at mail dot gmail dot com> <20160619164448 dot GA5245 at devel dot intra dot reserved-bit dot com> <CAOKbPbYpRcwJ8QNSgvW9BxkOeTSBnWEGGFRMOY=RSzoK6k1-Bw at mail dot gmail dot com> <20160620041246 dot GB5245 at devel dot intra dot reserved-bit dot com> <CAOKbPbZknCcBGozK_v8SC=PyJdczwr7ss6Y1y1hs2x8ag7cpxA at mail dot gmail dot com> <CAOKbPbY=Dus3hxVK0v785e2T8J3+hhat16ESQDtBLVKj6tyZew at mail dot gmail dot com>
On 06/22/2016 10:44 PM, Martin Galvan wrote:
> I've confirmed the test is failing because of a gdb bug:
(The difference is that nowadays gdb doesn't use libthread_db.so
thread create event breakpoints, which were masking the issue.)
> I'll be working on fixing that bug, but I don't think that should
> block the merging of this patch. Right now I'm using set
> scheduler-locking on to grab the child thread's ID for more rigurous
> testing. We can either leave it as it is, knowing it's a gdb bug, or
> remove the check for the child thread's ID (for now at least).
Can you work around it by setting a breakpoint that the child
trips on? Once the breakpoint triggers, you can switch back to
the parent, and continue/step it, and the child won't run further,
due to "set scheduler-locking on".
- Hang stepping over pthread_create?
Note that if there's synchronization (mutex/futex/whatnot) between
the parent/child threads inside glibc's pthread_create, then making gdb's
"set scheduler-locking on" lock the child thread _immediately_, such
that it is never ever scheduled -- that is, never let it run as soon as
we collect the initial PTRACE_EVENT_CLONE-injected SIGSTOP --
then trying to "step"/"next"/"continue to breakpoint" over pthread_create
will hang, with the parent waiting forever for the child to
unlock the mutex/futex/whatnot.
- Why it works with older GDBs, probably:
Since libthread_db thread create event breakpoints force synchronization
inside (see nptl/pthread_create.c:__pthread_create_2_1), it seems to me
that with older GDBs you don't see that hang by chance, because
the child still runs a bit before the thread create event breakpoint
is hit by the parent, probably enough to have the child unlock the