From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21428 invoked by alias); 13 Nov 2012 15:21:56 -0000 Received: (qmail 21418 invoked by uid 22791); 13 Nov 2012 15:21:54 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Nov 2012 15:21:43 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 13 Nov 2012 15:21:41 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 13 Nov 2012 15:21:38 -0000 Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qADFLU1960096552 for ; Tue, 13 Nov 2012 15:21:30 GMT Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qADFLbNO018007 for ; Tue, 13 Nov 2012 08:21:37 -0700 Received: from BR87Z6LW (dyn-9-152-212-247.boeblingen.de.ibm.com [9.152.212.247]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qADFLaLk017961; Tue, 13 Nov 2012 08:21:37 -0700 From: Andreas Arnez To: Pedro Alves Cc: jan.kratochvil@redhat.com, gdb@sourceware.org Subject: Re: Strange behavior of sigstep-threads.exp? References: <878vacnlem.fsf@linux.vnet.ibm.com> <50A125FD.8090504@redhat.com> Date: Tue, 13 Nov 2012 15:21:00 -0000 In-Reply-To: <50A125FD.8090504@redhat.com> (Pedro Alves's message of "Mon, 12 Nov 2012 16:38:21 +0000") Message-ID: <87vcd9le9r.fsf@linux.vnet.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii x-cbid: 12111315-1948-0000-0000-00000380A559 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00017.txt.bz2 Pedro Alves writes: > Whenever each of those single-steps is done, the other thread (let's > call it thread #2) is allowed to run free (the "set scheduler-locking > off" setting). Got it. Seems I misunderstood the "step" behavior in this case. Thanks for the explanation. >> On s390x the test case actually fails sometimes. In those cases, >> when stepping from step-1 to step-2, a ton of SIGUSR1 are indicated, >> and then the inferior seems to stop at the closing brace of the >> handler() function instead of the tgkill(). > > That does sound like something's wrong. Hacking the the test to force > "set debug infrun 1" and "set debug lin-lwp 1" would be my first move. As soon as "lin-lwp" debugging is turned on the test always seems to succeed. But with "debug infrun" alone the failure still occurs, and I observe the following: 1. The stepped thread reaches the last instruction inside the stepping range. 2. After resuming the stepped thread again, it traps at getpid@plt. Which is curious, because getpid() shouldn't be called until the instruction _after_ the stepping range. It seems like the trap for that instruction was missed somehow. (In the good case the thread always traps at the subroutine call, before having carried out the call.) 3. The thread is single-stepped until the jump to getpid(). The getpid() invocation itself is skipped with a step-resume breakpoint on the instruction after the original subroutine call. 4. The step-resume breakpoint is reached. Despite now being well outside the original stepping range, the thread is resumed. Upon the next trap, an updated stepping range is shown, adjusted to fit the line of the tgkill(). Then stepping continues until the next line, which is the closing brace. > I wonder if this makes a difference? > > gdb/infrun.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index de2cf19..9621b84 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -4698,8 +4698,10 @@ process_event_stop_test: > ecs->event_thread = tp; > ecs->ptid = tp->ptid; > context_switch (ecs->ptid); > - keep_going (ecs); > - return; > + > + /* Keep checking. The stepped thread might have already > + reached its destination, but not have reported it yet. > + If we just kept going, we could end up overstepping. */ > } > } Yes, it does make a difference. The test case still fails at a similar rate as before, but this time after "continue", because the inferior reaches "assert (0)". Again, I can not reproduce this failure with "set debug infrun 1" and "set debug lin-lwp 1".