This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/18261] New: watchthreads.exp random fails on !target_stopped_data_address targets (s390)


https://sourceware.org/bugzilla/show_bug.cgi?id=18261

            Bug ID: 18261
           Summary: watchthreads.exp random fails on
                    !target_stopped_data_address targets (s390)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com

watchthreads.exp is randomly failing on s390x-linux-gnu, like this:

 FAIL: gdb.threads/watchthreads.exp: threaded watch loop
 FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30

Enabling infrun/lin-lwp logging reveals the problem.

Below, LWP 27098 is the thread of args[0], and
       LWP 27099 is the thread of args[1].

gdb.log:

 ...
 LNW: waitpid(-1, ...) returned 27099, ERRNO-OK
 LLW: waitpid 27099 received Trace/breakpoint trap (stopped)
 LLTA: KILL(SIG0) Thread 0x3fffd508910 (LWP 27099) (OK)
 CSBB: Thread 0x3fffd508910 (LWP 27099) stopped by hardware
breakpoint/watchpoint
 LNW: waitpid(-1, ...) returned 27098, ERRNO-OK
 LLW: waitpid 27098 received Trace/breakpoint trap (stopped)
 LLTA: KILL(SIG0) Thread 0x3fffdd08910 (LWP 27098) (OK)
 CSBB: Thread 0x3fffdd08910 (LWP 27098) stopped by hardware
breakpoint/watchpoint
 ...

above, two threads stopped for a watchpoint at the same time.

 ...

 SEL: Found 2 events, selecting #0
 LLW: trap ptid is Thread 0x3fffd508910 (LWP 27099).
 LLW: exit
 sigchld
 infrun: target_wait (-1.0.0, status) =
 infrun:   27095.27099.0 [Thread 0x3fffd508910 (LWP 27099)],
 infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x800008ca
 infrun: stopped by watchpoint
 infrun: (no data address available)
 infrun: context switch
 infrun: Switching context from Thread 0x3fffdd08910 (LWP 27098) to Thread
0x3fffd508910 (LWP 27099)
 infrun: BPSTAT_WHAT_STOP_NOISY
 infrun: stop_waiting
 Hardware watchpoint 2: args[0]

 Old value = 2
 New value = 3
 Hardware watchpoint 3: args[1]

 Old value = 2
 New value = 3
 0x00000000800008ca in thread_function (arg=0x1) at
../../../src/gdb/testsuite/gdb.threads/watchthreads.c:74
 74        (*myp) ++; usleep (1);  /* Loop increment.  */



linux-nat.c reported the watchpoint hit of thread argv[1] first (note
"arg=0x1" in the frame line).  However, on targets that can't tell
which data address triggered the watchpoint, gdb reports all
watchpoint hits at the same time.  Recall that the watchpoint hit
event of argv[0] is still pending on the target side.

 (gdb) continue
 Continuing.
 infrun: clear_proceed_status_thread (Thread 0x3fffbd08910 (LWP 27102))
 infrun: clear_proceed_status_thread (Thread 0x3fffc508910 (LWP 27101))
 infrun: clear_proceed_status_thread (Thread 0x3fffcd08910 (LWP 27100))
 infrun: clear_proceed_status_thread (Thread 0x3fffd508910 (LWP 27099))
 infrun: clear_proceed_status_thread (Thread 0x3fffdd08910 (LWP 27098))
 infrun: clear_proceed_status_thread (Thread 0x3fffdd096f0 (LWP 27095))
 infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread 0x3fffd508910 (LWP 27099)] at 0x800008ca
 LLR: Preparing to resume process 27095, 0, inferior_ptid Thread 0x3fffd508910
(LWP 27099)
 RC: Resuming sibling Thread 0x3fffbd08910 (LWP 27102), 0, resume
 RC: Resuming sibling Thread 0x3fffc508910 (LWP 27101), 0, resume
 RC: Resuming sibling Thread 0x3fffcd08910 (LWP 27100), 0, resume
 RC: Not resuming sibling Thread 0x3fffdd08910 (LWP 27098) (has pending)
 RC: Resuming sibling Thread 0x3fffdd096f0 (LWP 27095), 0, resume
 LLR: PTRACE_CONT Thread 0x3fffd508910 (LWP 27099), 0 (resume event thread)
 sigchld

The argv[1] thread (LWP 27099) doesn't have a pending event, so it is
resumed...

 linux_nat_wait: [process -1], [TARGET_WNOHANG]
 LLW: enter
 LLW: Using pending wait status Trace/breakpoint trap (stopped) for Thread
0x3fffdd08910 (LWP 27098).

The backend notices the pending event for the argv[0] thread
(LWP 27098) (recall this watchpoint hit has already been reported).

 SC:  kill Thread 0x3fffbd08910 (LWP 27102) **<SIGSTOP>**
 SC:  lwp kill 0 ERRNO-OK
 SC:  kill Thread 0x3fffc508910 (LWP 27101) **<SIGSTOP>**
 SC:  lwp kill 0 ERRNO-OK
 SC:  kill Thread 0x3fffcd08910 (LWP 27100) **<SIGSTOP>**
 SC:  lwp kill 0 ERRNO-OK
 SC:  kill Thread 0x3fffd508910 (LWP 27099) **<SIGSTOP>**
 SC:  lwp kill 0 ERRNO-OK

The backend starts stopping all threads.

 WL: about to sigsuspend
 sigchld
 WL: about to sigsuspend
 sigchld
 WL: waitpid Thread 0x3fffbd08910 (LWP 27102) received Stopped (signal)
(stopped)
 SWC: Expected SIGSTOP caught for Thread 0x3fffbd08910 (LWP 27102).
 WL: waitpid Thread 0x3fffc508910 (LWP 27101) received Stopped (signal)
(stopped)
 SWC: Expected SIGSTOP caught for Thread 0x3fffc508910 (LWP 27101).
 WL: waitpid Thread 0x3fffcd08910 (LWP 27100) received Stopped (signal)
(stopped)
 SWC: Expected SIGSTOP caught for Thread 0x3fffcd08910 (LWP 27100).
 WL: waitpid Thread 0x3fffd508910 (LWP 27099) received Trace/breakpoint trap
(stopped)
 SWC: Pending event Trace/breakpoint trap (stopped) in Thread 0x3fffd508910
(LWP 27099)
 CSBB: Thread 0x3fffd508910 (LWP 27099) stopped by hardware
breakpoint/watchpoint
 WL: waitpid Thread 0x3fffdd096f0 (LWP 27095) received Stopped (signal)
(stopped)
 SWC: Expected SIGSTOP caught for Thread 0x3fffdd096f0 (LWP 27095).

While waiting for the SIGSTOPs, thread args[1] (LWP 27099) trips again
on its watchpoint.

 SEL: Found 2 events, selecting #1
 LLW: trap ptid is Thread 0x3fffdd08910 (LWP 27098).
 LLW: exit

The backend reports the old event for the args[0] thread.

 infrun: target_wait (-1.0.0, status) =
 infrun:   27095.27098.0 [Thread 0x3fffdd08910 (LWP 27098)],
 infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x800008ca
 infrun: stopped by watchpoint
 infrun: (no data address available)
 infrun: context switch
 infrun: Switching context from Thread 0x3fffd508910 (LWP 27099) to Thread
0x3fffdd08910 (LWP 27098)
 infrun: BPSTAT_WHAT_STOP_NOISY
 infrun: stop_waiting
 [Switching to Thread 0x3fffdd08910 (LWP 27098)]
 Hardware watchpoint 3: args[1]

 Old value = 3
 New value = 4
 0x00000000800008ca in thread_function (arg=0x0) at
../../../src/gdb/testsuite/gdb.threads/watchthreads.c:74
 74        (*myp) ++; usleep (1);  /* Loop increment.  */

the args[0] 2->3 transition of watchpoint 2 (what caused this event)
has already been reported.  But, since this is a
!target_stopped_data_address target, GDB also notices that args[1] has
meanwhile changed too (there's an event for this watchpoint 3 pending
in the backend), and thus reports watchpoint 3.

(gdb) FAIL: gdb.threads/watchthreads.exp: threaded watch loop

This is a fail because the test expects that when only one watchpoint
hit is reported to the user, the "arg=0x0" matches the thread that
caused the watchpoint.  In this case, the test was expecting "arg=0x1".

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]