From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id V7eOFnPM/2dq6jYAWB0awg (envelope-from ) for ; Wed, 16 Apr 2025 11:27:47 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Ug9WYRh/; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4622C1E0C3; Wed, 16 Apr 2025 11:27:47 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A99821E05C for ; Wed, 16 Apr 2025 11:27:46 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3090A3858019 for ; Wed, 16 Apr 2025 15:27:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3090A3858019 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Ug9WYRh/ Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 66EBE3858C41 for ; Wed, 16 Apr 2025 15:27:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66EBE3858C41 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 66EBE3858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744817231; cv=none; b=CCRmleIsRacT32n9cneIt3tKq2NtCUaP90FOI5JUXYRe7/zrW6Ac4Go0mZPqD/d0WB9q/chw/w3e5Y7q4wCdBoreKQL+g3xbttW/a8LnlNmoBQni5Y7MOb1F8uYB2MvLENhwxnbwuNxKL2RPPL2yE0Xeg+Cm6uNGz5TFU+TlZDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744817231; c=relaxed/simple; bh=o9oM3tEw39lp8rNfoswfeaKCFx/OVBSWN4Gd1v2B6JA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=r9d4qQL6/Bc0gnKcMmZ1DkDDA1+vMWHcPw//hygpitxVOA/Bt0+fWGxp8A5ZF3mRHsi9UW11LFjl3nRnURkrvR/mqJ+Y22VEpvrh+Jh6RmnrQMn1TxfWU4kj3kGlB8IM1J+eHCZVBitavi1yDuNARUD7Zze8n/zmdnbryIoDQJM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66EBE3858C41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744817231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U64KbvvBN9tna1IHDvTG42HvHr1q7a78JmTgN5tkvIQ=; b=Ug9WYRh/25bc+g32gBavyn4f9xyA/cwRzsv+Bx4eaIyU2Szc3C88/PiXEhMsaAJT38wBHK p3tF/+DJACMQBuPYdTu5ofB6AzuzzfwF9AZVVhnSTmTrAo/TUeL2dS9qBVsKaeKK/KAe8N pM9Hl3kPkGASgzXCVgLS84Wa/W867Tg= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-517-WtsVQW_IONOVeZxJFb845A-1; Wed, 16 Apr 2025 11:27:08 -0400 X-MC-Unique: WtsVQW_IONOVeZxJFb845A-1 X-Mimecast-MFC-AGG-ID: WtsVQW_IONOVeZxJFb845A_1744817227 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-2ff53a4754aso9409320a91.2 for ; Wed, 16 Apr 2025 08:27:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744817227; x=1745422027; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U64KbvvBN9tna1IHDvTG42HvHr1q7a78JmTgN5tkvIQ=; b=xPBzIMm+M5KWhZO5n4jgeFYZxDxUq31OBt1Oy9So22HyhxhD9VnUeYmzo/Ebhou+1j fa0QGquHU9n7fnKanNfHGJOorD5Zwdmn/UkcnZUnDm2LTgOIQqak4rkSiZpMufEt0EZb gkfENjwrKXei5kgBe+spTc0KKXEDUHY1/yxDIq4XRIVA9R4mTXyi747e4t1hp+AjY+KJ TcF5vWu0rmGRmKOcaXqzxZ1f75z2w03ztVMKtuDaW/ib+ARODwmaSGqGwFZeqzE1VUzb /7wxGAFh5aSC1uc2fPM2aTaseKVsap8wfTH7LMD977DQ/2fKySPRv4XkI1sSxHSH4Tpy 0X8Q== X-Gm-Message-State: AOJu0Yz7iMAuf0AsC6SK0eqtYeonzGlNNNeIsGUqNdCZOjFR9gnedHbf 0EA4232LDJxE0WEYYADzVtqx0ZKhTHmLpuulEMh6FwACK8btXm6Tj2HQ4Bayj08Nx9BxX4qZShb rQSnOmRIlhvE4ph8mWKCpcGm28MmXvc2BNLoTcVtPPo/UZSJVtBpdiVm37HUrA5VQYFoWWYUwJ6 7x8LOCm/38gc6YzzsUlSipNcu8okbWT8Jmug== X-Gm-Gg: ASbGnctNAW6rqhLP5KRnTtzUKBRdXiL7gYFpFKBTSZtodkxfRGtS4E1D3HChWTy1Pr7 PFjOqriJXDbSL0xlUA3UH+5Xh1sENcqtgT14PKteI1dyUc/1CfOJJVILFoE6kifDYP0UjFVo= X-Received: by 2002:a17:90b:58cd:b0:2fe:b016:a6ac with SMTP id 98e67ed59e1d1-30864025039mr4010071a91.15.1744817227304; Wed, 16 Apr 2025 08:27:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHUxAuK24UyLkuI0LcofLW5CxLkdcqYVxafKguzRiu9bqhzhtahO54QoSSDySLaELXDyfjdwQXOrKJtOhPs+GU= X-Received: by 2002:a17:90b:58cd:b0:2fe:b016:a6ac with SMTP id 98e67ed59e1d1-30864025039mr4010040a91.15.1744817227035; Wed, 16 Apr 2025 08:27:07 -0700 (PDT) MIME-Version: 1.0 References: <20250414115102.1991-1-tdevries@suse.de> In-Reply-To: <20250414115102.1991-1-tdevries@suse.de> From: Alexandra Petlanova Hajkova Date: Wed, 16 Apr 2025 17:26:55 +0200 X-Gm-Features: ATxdqUHDMi9UH_p7J_VrIP-2T4QE_snhdw6gGC2D4LYDZp0257HW5hf-QDa797I Message-ID: Subject: Re: [PATCH] [gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp To: Tom de Vries Cc: gdb-patches@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: xMEfEU9qo-iDGn_AeZhZtMJuvzKMTJJvha-of233P-s_1744817227 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000041bbd0632e6eb8b" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org --000000000000041bbd0632e6eb8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 14, 2025 at 1:51=E2=80=AFPM Tom de Vries wro= te: > With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into = a > timeout: > ... > (gdb) c 1& > Will stop next time breakpoint 1 is reached. Continuing. > (gdb) PASS: $exp: c 1&: c 1& > > Breakpoint 2, foo () at bg-execution-repeat.c:23 > 23 return 0; /* set break here */ > PASS: $exp: c 1&: breakpoint hit 1 > > Will stop next time breakpoint 2 is reached. Continuing. > (gdb) PASS: $exp: c 1&: repeat bg command > print 1 > $1 =3D 1 > (gdb) PASS: $exp: c 1&: input still accepted > interrupt > (gdb) PASS: $exp: c 1&: interrupt > > Program received signal SIGINT, Interrupt. > foo () at bg-execution-repeat.c:24 > 24 } > PASS: $exp: c 1&: interrupt received > set var do_wait=3D0 > (gdb) PASS: $exp: c 1&: set var do_wait=3D0 > continue& > Continuing. > (gdb) PASS: $exp: c 1&: continue& > FAIL: $exp: c 1&: breakpoint hit 2 (timeout) > ... > > I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = =3D > 1" > in the .c file. > > The timeout happens as follows: > - with the inferior stopped at main, gdb continues (command c 1&) > - the inferior hits the breakpoint at foo > - gdb continues (using the repeat command functionality) > - the inferior is interrupted > - inferior variable do_wait gets set to 0. The assumption here is that t= he > inferior has progressed enough that do_wait is set to 1 at that point, > but > that happens not to be the case. Consequently, this has no effect. > - gdb continues > - the inferior sets do_wait to 1 > - the inferior enters the wait function, and wait for do_wait to become 0= , > which never happens. > > Fix this by moving the "do_wait =3D 1" to before the first call to foo. > > Tested on x86_64-linux. > --- > Hi Tom, I also tested this on aarch64 and it works as expected, I think it's a reasonable change. Reviewed-By: Alexandra Petlanova Hajkova --000000000000041bbd0632e6eb8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 14,= 2025 at 1:51=E2=80=AFPM Tom de Vries <tdevries@suse.de> wrote:
With test-case gdb.base/bg-execution-repeat.exp, occasio= nally I run into a
timeout:
...
(gdb) c 1&
Will stop next time breakpoint 1 is reached.=C2=A0 Continuing.
(gdb) PASS: $exp: c 1&: c 1&

Breakpoint 2, foo () at bg-execution-repeat.c:23
23=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0; /* set break here */
PASS: $exp: c 1&: breakpoint hit 1

Will stop next time breakpoint 2 is reached.=C2=A0 Continuing.
(gdb) PASS: $exp: c 1&: repeat bg command
print 1
$1 =3D 1
(gdb) PASS: $exp: c 1&: input still accepted
interrupt
(gdb) PASS: $exp: c 1&: interrupt

Program received signal SIGINT, Interrupt.
foo () at bg-execution-repeat.c:24
24=C2=A0 =C2=A0 =C2=A0 }
PASS: $exp: c 1&: interrupt received
set var do_wait=3D0
(gdb) PASS: $exp: c 1&: set var do_wait=3D0
continue&
Continuing.
(gdb) PASS: $exp: c 1&: continue&
FAIL: $exp: c 1&: breakpoint hit 2 (timeout)
...

I can reproduce it reliably by adding a "sleep (1)" before the &q= uot;do_wait =3D 1"
in the .c file.

The timeout happens as follows:
- with the inferior stopped at main, gdb continues (command c 1&)
- the inferior hits the breakpoint at foo
- gdb continues (using the repeat command functionality)
- the inferior is interrupted
- inferior variable do_wait gets set to 0.=C2=A0 The assumption here is tha= t the
=C2=A0 inferior has progressed enough that do_wait is set to 1 at that poin= t, but
=C2=A0 that happens not to be the case.=C2=A0 Consequently, this has no eff= ect.
- gdb continues
- the inferior sets do_wait to 1
- the inferior enters the wait function, and wait for do_wait to become 0,<= br> =C2=A0 which never happens.

Fix this by moving the "do_wait =3D 1" to before the first call t= o foo.

Tested on x86_64-linux.
---
=C2=A0
Hi Tom,

I also tested this= on aarch64 and it works as expected, I think it's a reasonable change.=

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
--000000000000041bbd0632e6eb8b--