Re: Run process-dies-while-detaching.exp with SW watchpoint

[Pedro Alves <palves at redhat dot com>]

On 08/23/2016 03:47 PM, Yao Qi wrote:
> 
> Hi,
> I see the following fail when I run tests on some ARM board without
> HW watchpoint support,
> 
> (gdb) watch globalvar^M
> Watchpoint 2: globalvar^M
> (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: watch globalvar
> 
> I think we should run test_detach_watch with both HW watchpoint and SW
> watchpoint.  I modified it, as the patch shown below, but the
> test_detach_watch with SW watchpoint causes some test fails even on
> x86_64,
> 
> Thread 12 "process-dies-wh" hit Temporary breakpoint 3, 0x00002aaaaafaf2d0 in _exit () from /lib/x86_64-linux-gnu/libc.so.6^M
> (gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint hw=0: continue to breakpoint: _exit
> continue^M
> Continuing.^M
> Cannot find user-level thread for LWP 2363: generic error^M
> (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint hw=0: continue
> 
> When the error is thrown, the stack backtrace is 
> 
> (gdb) bt 10
> #0  thread_from_lwp (ptid=...) at /home/yao/SourceCode/gnu/gdb/git/gdb/linux-thread-db.c:356
> #1  0x0000000000460fb4 in thread_db_wait (ops=<optimised out>, ptid=..., ourstatus=0x7fff702c0510, options=1)
>     at /home/yao/SourceCode/gnu/gdb/git/gdb/linux-thread-db.c:1146
> #2  0x00000000005b69cd in delegate_wait (self=<optimised out>, arg1=..., arg2=<optimised out>, arg3=<optimised out>)
>     at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:116
> #3  0x00000000005c5bb4 in target_wait (ptid=..., status=status@entry=0x7fff702c0510, options=options@entry=1)
>     at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:2289
> #4  0x0000000000578269 in do_target_wait (ptid=..., status=status@entry=0x7fff702c0510, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3641
> #5  0x0000000000583a1b in fetch_inferior_event (client_data=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3952
> #6  0x0000000000598cd5 in gdb_wait_for_event (block=block@entry=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:859
> #7  0x0000000000598ee5 in gdb_do_one_event () at /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:322
> #8  0x0000000000598f55 in start_event_loop () at /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:371
> #9  0x0000000000592d18 in captured_command_loop (data=data@entry=0x0) at /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:324
> 
> and the "ourstatus" got from beneath->to_wait is
> 
> (gdb) p *ourstatus
> $1 = {kind = TARGET_WAITKIND_STOPPED, value = {integer = 5, sig = GDB_SIGNAL_TRAP, related_pid = {pid = 5, lwp = 0, tid = 0}, 
>     execd_pathname = 0x5 <error: Cannot access memory at address 0x5>, syscall_number = 5}}
> 
> looks linux-nat target thinks the thread is stopped, but thread-db can't
> find the thread.  Is it a known problem (in gdb or glibc)?
> 

Doesn't this just mean that the process died meanwhile?
That's the point of the test.  /proc/TID/status probably shows
that the thread is now zombie.

BTW, software watchpoints aren't defined very well with threads,
but, it sounds like you'd get the same problem if you single-step
all the way to exit instead of "continue", which in effect is what
a software watchpoint does.

Thanks,
Pedro Alves