From patchwork Mon Feb 6 11:54:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 64346 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A018C3858C30 for ; Mon, 6 Feb 2023 11:54:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A018C3858C30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675684465; bh=jYMX8TJdCQ6/B7syc079IeLjWjx/7yBdkt7OROs+UMw=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=Hfz3qLkCWNaFNXyNs2j00YE//rzclfDEF+TIR2/7YuM3JNo9XKybc2hdKQrRQjNJJ iniMaZQhhda9+xOzB2PsKcx5hicCM4BwMZBYTvBW38nQZAYFyl2xUHQXVTh6lwov/Q GDw8hYh/AJvVkpJrGiFYVMKSthbUwwKdTg4Mv8WQ= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 572783858D1E for ; Mon, 6 Feb 2023 11:54:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 572783858D1E Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 94CCC3F413 for ; Mon, 6 Feb 2023 11:54:02 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 7FA1313334 for ; Mon, 6 Feb 2023 11:54:02 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id 1IDvHVrq4GMrPQAAGKfGzw (envelope-from ) for ; Mon, 06 Feb 2023 11:54:02 +0000 To: gdb-patches@sourceware.org Subject: [pushed] [gdb/testsuite] Fix gdb.threads/schedlock.exp on fast cpu Date: Mon, 6 Feb 2023 12:54:01 +0100 Message-Id: <20230206115401.16137-1-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Tom de Vries via Gdb-patches From: Tom de Vries Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" Occasionally, I run into: ... (gdb) PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \ set scheduler-locking on continue^M Continuing.^M PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \ 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=on: cmd=continue: \ 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 makes the wrap defined behaviour (and which also make the loop run twice as long, 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 adding an "alarm (30)". Tested on x86_64-linux. PR testsuite/30074 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30074 --- gdb/testsuite/gdb.threads/schedlock.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) base-commit: 023b960d59c25994da233ea371deb26105fbacc8 diff --git a/gdb/testsuite/gdb.threads/schedlock.c b/gdb/testsuite/gdb.threads/schedlock.c index 5422c64fd99..c4e77948ad4 100644 --- a/gdb/testsuite/gdb.threads/schedlock.c +++ b/gdb/testsuite/gdb.threads/schedlock.c @@ -24,7 +24,7 @@ void *thread_function(void *arg); /* Pointer to function executed by each thread #define NUM 1 -unsigned int args[NUM+1]; +unsigned long long int args[NUM+1]; int main() { int res; @@ -32,6 +32,8 @@ int main() { void *thread_result; long i; + alarm (30); + for (i = 1; i <= NUM; i++) { args[i] = 1; @@ -72,13 +74,14 @@ volatile int call_function = 0; void *thread_function(void *arg) { int my_number = (long) arg; - int *myp = (int *) &args[my_number]; + unsigned long long int *myp = (unsigned long long int *) &args[my_number]; + volatile unsigned int cnt = 0; - /* Don't run forever. Run just short of it :) */ - while (*myp > 0) + while (1) { /* schedlock.exp: main loop. */ MAYBE_CALL_SOME_FUNCTION(); (*myp) ++; + cnt++; } pthread_exit(NULL);