Re: x86_64-m32 internal error for multi-thread-step.exp [Re: [PATCH v10 06/28] btrace: change branch trace data structure]

[Pedro Alves <palves at redhat dot com>]

On 01/22/2015 12:29 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Metzger, Markus T
>> Sent: Tuesday, January 20, 2015 4:08 PM
>> To: Jan Kratochvil
>> Cc: palves@redhat.com; gdb-patches@sourceware.org
> 
> 
>> I can't reproduce this fail; I don't get that far.  This test fails for me with
>>
>> 	FAIL: gdb.btrace/multi-thread-step.exp: continue to breakpoint: cont
>> to multi-thread-step.c:34 (timeout)
> 
> This fail seems to be caused by 588dcc3edbde19f90e76de969dbfa7ab3e17951a
> "Consolidate the custom TUI query hook with the default query hook".  It is not
> related to btrace.
> 
> The failing test program looks like this:
> 
>     pthread_barrier_wait (&barrier);
>     global = 42; /* bp.1 */
>     pthread_barrier_wait (&barrier);
> 
> There are two threads, both are at bp.1 between the two barriers.  When I now
> delete all breakpoints like this:
> 
>     (gdb) del
>     Delete all breakpoints? (y or n) y
> 
> and then continue the inferior, only the current thread is resumed.  The other
> thread remains at its current location.  The resumed thread waits at the barrier
> and the test runs into a timeout.
> 
> Here's a complete debug session:
> 
>     (gdb) b 30
>     Breakpoint 1 at 0x400776: file gdb.btrace/multi-thread-step.c, line 30.
>     (gdb) r
>     Starting program: gdb.btrace/multi-thread-step 
>     [Thread debugging using libthread_db enabled]
>     Using host libthread_db library "/lib64/libthread_db.so.1".
>     [New Thread 0x7ffff7fce700 (LWP 22156)]
> 
>     Breakpoint 1, test (arg=0x0) at gdb.btrace/multi-thread-step.c:30
>     30	  global = 42; /* bp.1 */
>     (gdb) del
>     Delete all breakpoints? (y or n) y
>      (gdb) info thr
>       Id   Target Id         Frame 
>       2    Thread 0x7ffff7fce700 (LWP 22156) "multi-thread-st" test (arg=0x0) at gdb.btrace/multi-thread-step.c:30
>     * 1    Thread 0x7ffff7fcf740 (LWP 22152) "multi-thread-st" test (arg=0x0) at gdb.btrace/multi-thread-step.c:30
>     (gdb) c
>     Continuing.
>     ^C
>     Program received signal SIGINT, Interrupt.
>     0x000000384380c20c in pthread_barrier_wait () from /lib64/libpthread.so.0
>     (gdb) info thr
>       Id   Target Id         Frame 
>       2    Thread 0x7ffff7fce700 (LWP 22156) "multi-thread-st" test (arg=0x0) at gdb.btrace/multi-thread-step.c:30
>     * 1    Thread 0x7ffff7fcf740 (LWP 22152) "multi-thread-st" 0x000000384380c20c in pthread_barrier_wait () from     /lib64/libpthread.so.0
> 
> When I set debug infrun, I get the this:
> 
>     (gdb) del
>     Delete all breakpoints? (y or n) y
>      (gdb)
>     infrun: target_wait (-1, status) =
>     infrun:   -1 [process -1],
>     infrun:   status->kind = no-resumed
>     infrun: TARGET_WAITKIND_NO_RESUMED (ignoring)
>     infrun: prepare_to_wait
> 
> I don't see this with the old query behaviour or when I remove breakpoints like this
> 
>     (gdb) del 1

Hmm, gdb_readline_wrapper believes the target was async to begin
with.  That seems to be an issue with linux_nat_is_async_p.  And
then, gdb_readline_wrapper_cleanup sets the target async again,
which triggers the target_wait call.  It's normal that only
one thread is resumed, because the other thread has an event
pending already.  Normally that works because at the very end of
linux_nat_resume, we'll re-enable async, which, if we were
sync before, tells the event loop to poll them.  But in this
case, we're reaching linux_nat_resume already async, do nothing
wakes up the event loop, and so the pending event is never
collected and handled by infrun.

Let me see if I can come up with a fix.

Thanks,
Pedro Alves