From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 447413857437; Mon, 6 Feb 2023 11:52:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 447413857437 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675684376; bh=MAFrlP1mx3GIFYNgWUYn+Tj2x4My2W7TOrG49R2HZ08=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iB6cIJWUoGtPDsMLkmPyPLql3NTp4BGGWXSzV66PF9KVol1e+AVSR+NASgwIkbGMo /v9znBbJ2qvjSvvQ9JcM5j8Kf4rIxsAmFwieOz50FEK3LfDUXVqARK+Bu5LaNTgCHP /HUm0fKEI3Rk3Hav5yGOOYIU/TDQYdBOcSN6qoxU= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug testsuite/30074] FAIL: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: stop all threads (with lock) (timeout) Date: Mon, 06 Feb 2023 11:52:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30074 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D9af467b82406= 614deb46151f838c336a7c8604db commit 9af467b82406614deb46151f838c336a7c8604db Author: Tom de Vries Date: Mon Feb 6 12:52:50 2023 +0100 [gdb/testsuite] Fix gdb.threads/schedlock.exp on fast cpu Occasionally, I run into: ... (gdb) PASS: gdb.threads/schedlock.exp: schedlock=3Don: cmd=3Dcontinue: \ set scheduler-locking on continue^M Continuing.^M PASS: gdb.threads/schedlock.exp: schedlock=3Don: cmd=3Dcontinue: \ continue (with lock) [Thread 0x7ffff746e700 (LWP 1339) exited]^M No unwaited-for children left.^M (gdb) Quit^M (gdb) FAIL: gdb.threads/schedlock.exp: schedlock=3Don: cmd=3Dcontinue: \ stop all threads (with lock) (timeout) ... What happens is that this loop which is supposed to run "just short of forever": ... /* Don't run forever. Run just short of it :) */ while (*myp > 0) { /* schedlock.exp: main loop. */ MAYBE_CALL_SOME_FUNCTION(); (*myp) ++; } ... finishes after 0x7fffffff iterations (when a signed wrap occurs), which= on my system takes only about 1.5 seconds. Fix this by: - changing the pointed-at type of myp from signed to unsigned, which ma= kes the wrap defined behaviour (and which also make the loop run twice as lon= g, which is already enough to make it impossible for me to reproduce the FAIL. But let's try to solve this more structurally). - changing the pointed-at type of myp from int to long long, making the wrap unlikely. - making sure the loop runs forever, by setting the loop condition to 1. - making sure the loop still contains different lines (as far as debug = info is concerned) by incrementing a volatile counter in the loop. - making sure the program doesn't run forever in case of trouble, by ad= ding an "alarm (30)". Tested on x86_64-linux. PR testsuite/30074 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30074 --=20 You are receiving this mail because: You are on the CC list for the bug.=