From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VgAYJlYNnmrFkDIAWB0awg (envelope-from ) for ; Sun, 06 Sep 2026 21:03:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1788742998; bh=qtDGQKnIOvNWAxms/jCAf6fAyiKGiCyreOLzkEidNko=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=buI4SCQcvcGI5JHttmKs+lgpxrpYw8Qs11sH1SNIdhlxA25miBziT1MfA6c7jHZut eB/Bm4cgCq/zR0X0Op5j4h0kGFkCf9mC78iIPveMg/nwZet7QN1f0dS/RtusICgB4E PtSrEJSkBjwz6c5nLFZv09pLY1LDf+0yL2PMXyfA= Received: by simark.ca (Postfix, from userid 112) id 830E31E09E; Sun, 06 Sep 2026 21:03:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=oo/tzxA9; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 F07DD1E033 for ; Sun, 06 Sep 2026 21:03:16 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7709E4BC7EF8 for ; Mon, 7 Sep 2026 01:03:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7709E4BC7EF8 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=oo/tzxA9 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 695174BA2E31 for ; Mon, 7 Sep 2026 01:02:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 695174BA2E31 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 695174BA2E31 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788742971; cv=none; b=kvEysuJZuOdJkDd01HQmdRdnPA+BKdYdKErV8A13QonNcBI/3e0XLiDeST+9Leb9jlwlOHkx1B4oxyJgkcDx/pALbHZFkABSrQnZfrWcTXDmLwmn7McFvMnJs0IxDptAmw5PbXlQWe7JAocJsCXGqPJIYDaGDsBlw8uolNAinok= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788742971; c=relaxed/simple; bh=qtDGQKnIOvNWAxms/jCAf6fAyiKGiCyreOLzkEidNko=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=wUE+lkTWxjHUWqmQujct3E+3I0+KCV7H2u0IyMlv52auJSY7LC6hZc0qpHyf/Bl7dRoh99ZRXm8FBbN8Iiz/avYjxe5x+G1EIfcltaXnMxFg13QKwN4auvBCHItc+G9jKrWSg3wHlvKw7si3oG/f52MJnngjqNai6+0N/dtp9M4= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=oo/tzxA9 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 695174BA2E31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1788742970; bh=qtDGQKnIOvNWAxms/jCAf6fAyiKGiCyreOLzkEidNko=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=oo/tzxA9ogopw069NucEm3ryx5Q/ObrN5ntbhOF0zohwIvoRZbgq4BPEL80tmYsSD YJv0BTiy+y8tjZJ/gDnnQN7g+enpKYgFulawQFp6cU02djXjrK3xEe/j1tZf37Xulp /sR/HiP0bODZqDCCrx4vi2ZI6jBrm8MxcuKX3rZQ= Received: by simark.ca (Postfix) id B8F5A1E033; Sun, 06 Sep 2026 21:02:49 -0400 (EDT) Message-ID: <26f8c856-5194-4fec-9314-fbd30473f493@simark.ca> Date: Sun, 6 Sep 2026 21:02:49 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values To: Thiago Jung Bauermann , Tom de Vries Cc: gdb-patches@sourceware.org References: <20260906040140.158197-1-thiago.bauermann@linaro.org> <87bjaannoi.fsf@linaro.org> Content-Language: en-US From: Simon Marchi In-Reply-To: <87bjaannoi.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 On 2026-09-06 16:13, Thiago Jung Bauermann wrote: > Tom de Vries writes: > >> On 9/6/26 6:01 AM, Thiago Jung Bauermann wrote: >>> In the three Linux machines I tested (my x86_64 laptop and two aarch64 >>> servers), gdb.gdb/python-helper.exp has this timeout failure: >>> FAIL: gdb.gdb/python-helper.exp: pretty print type instance flags (timeout) >>> And the slower aarch64 server also has this one: >>> FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout) >>> Fix these failures by using timeout factors. For the latter, a 2x factor >>> is enough. For the former, I needed 8x. It appears that the "pretty print >>> type instance flags" test is quite demanding. >> >> I tried to see if I could reproduce this. I ended up writing a patch ( >> https://sourceware.org/pipermail/gdb-patches/2026-September/230135.html ) for some timeout >> but I have no idea whether it's the same root cause or not. You may want to test it. >> >> Assuming it's not, LGTM. >> >> Approved-By: Tom de Vries > > Thank you! I tested your patch. The same timeouts still happen. > > BUT: > >>> --- >>> I actually noticed these failures because I compared GDB 17.2 test >>> results with GDB 18 ones. OK to also push to the branch? >> >> This makes me wonder if we're dealing with a performance regression here, but yeah, I >> suppose it's ok. > > And from Simon's email: > >> Out of curiosity, is this with GDB build at -O0 or -O2 (or something >> else)? With ASan or other instrumentation? >> >> I am asking because if it's -O2, then it's representative of what a user >> would have in their hands. If some commands take a minute to run, then >> we could at least check if it's because GDB is doing something terribly >> inefficient. > > Your responses made me realise I may be the only one seeing these > timeouts, even if it's accross three machines. I found out that this is > because I compile my test builds with -D_GLIBCXX_DEBUG. I hadn't > realized until now that its impact on GDB performance was so big: > > Without -D_GLIBCXX_DEBUG on the slower aarch64 server: > > $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit > Reading symbols from gdb... > Time for "minsym install worker": wall 0.237, user 0.135, sys 0.013, user+sys 0.148, 62.4 % CPU > Time for "minsym install worker": wall 0.238, user 0.139, sys 0.003, user+sys 0.142, 59.7 % CPU > Time for "minsym install worker": wall 0.239, user 0.141, sys 0.005, user+sys 0.146, 61.1 % CPU > Time for "minsym install worker": wall 0.248, user 0.148, sys 0.009, user+sys 0.157, 63.3 % CPU > Time for "minsym install worker": wall 0.249, user 0.154, sys 0.003, user+sys 0.157, 63.1 % CPU > Time for "minsym install worker": wall 0.252, user 0.143, sys 0.007, user+sys 0.150, 59.5 % CPU > Time for "minsym install worker": wall 0.256, user 0.151, sys 0.003, user+sys 0.154, 60.2 % CPU > Time for "minsym install worker": wall 0.260, user 0.148, sys 0.004, user+sys 0.152, 58.5 % CPU > ⚠ warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb > line to your configuration file "/home/thiago.bauermann/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/thiago.bauermann/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > Time for "DWARF indexing worker": wall 0.623, user 0.585, sys 0.035, user+sys 0.620, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.623, user 0.586, sys 0.034, user+sys 0.620, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.623, user 0.597, sys 0.023, user+sys 0.620, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.623, user 0.588, sys 0.033, user+sys 0.621, 99.7 % CPU > Time for "DWARF indexing worker": wall 0.625, user 0.597, sys 0.025, user+sys 0.622, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.625, user 0.576, sys 0.045, user+sys 0.621, 99.4 % CPU > Time for "DWARF indexing worker": wall 0.626, user 0.598, sys 0.025, user+sys 0.623, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.626, user 0.596, sys 0.029, user+sys 0.625, 99.8 % CPU > Time for "DWARF skeletonless type units": wall 0.001, user 0.001, sys 0.000, user+sys 0.001, 100.0 % CPU > Time for "DWARF add parent map": wall 0.089, user 0.087, sys 0.001, user+sys 0.088, 98.9 % CPU > Time for "DWARF finalize worker": wall 2.039, user 2.034, sys 0.002, user+sys 2.036, 99.9 % CPU > Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU > Time for "DWARF finalize worker": wall 2.045, user 2.040, sys 0.002, user+sys 2.042, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.055, user 2.051, sys 0.001, user+sys 2.052, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.082, user 2.077, sys 0.002, user+sys 2.079, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.087, user 2.082, sys 0.002, user+sys 2.084, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.103, user 2.096, sys 0.004, user+sys 2.100, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.112, user 2.107, sys 0.002, user+sys 2.109, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.114, user 2.110, sys 0.001, user+sys 2.111, 99.9 % CPU > > With -D_GLIBCXX_DEBUG on the slower aarch64 server: > > $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit > Reading symbols from gdb... > Time for "minsym install worker": wall 0.334, user 0.245, sys 0.011, user+sys 0.256, 76.6 % CPU > Time for "minsym install worker": wall 0.336, user 0.242, sys 0.012, user+sys 0.254, 75.6 % CPU > Time for "minsym install worker": wall 0.342, user 0.249, sys 0.008, user+sys 0.257, 75.1 % CPU > Time for "minsym install worker": wall 0.349, user 0.231, sys 0.015, user+sys 0.246, 70.5 % CPU > Time for "minsym install worker": wall 0.352, user 0.231, sys 0.019, user+sys 0.250, 71.0 % CPU > Time for "minsym install worker": wall 0.356, user 0.237, sys 0.012, user+sys 0.249, 69.9 % CPU > Time for "minsym install worker": wall 0.362, user 0.250, sys 0.009, user+sys 0.259, 71.5 % CPU > Time for "minsym install worker": wall 0.362, user 0.240, sys 0.017, user+sys 0.257, 71.0 % CPU > warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb > line to your configuration file "/home/thiago.bauermann/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/thiago.bauermann/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > Time for "DWARF indexing worker": wall 3.786, user 2.786, sys 0.847, user+sys 3.633, 96.0 % CPU > Time for "DWARF indexing worker": wall 3.786, user 2.711, sys 0.954, user+sys 3.665, 96.8 % CPU > Time for "DWARF indexing worker": wall 3.786, user 2.741, sys 0.933, user+sys 3.674, 97.0 % CPU > Time for "DWARF indexing worker": wall 3.787, user 2.822, sys 0.872, user+sys 3.694, 97.5 % CPU > Time for "DWARF indexing worker": wall 3.791, user 2.688, sys 0.979, user+sys 3.667, 96.7 % CPU > Time for "DWARF indexing worker": wall 3.791, user 2.771, sys 0.880, user+sys 3.651, 96.3 % CPU > Time for "DWARF indexing worker": wall 3.792, user 2.936, sys 0.778, user+sys 3.714, 97.9 % CPU > Time for "DWARF indexing worker": wall 3.793, user 2.762, sys 0.905, user+sys 3.667, 96.7 % CPU > Time for "DWARF skeletonless type units": wall 0.006, user 0.005, sys 0.000, user+sys 0.005, 83.3 % CPU > Time for "DWARF add parent map": wall 0.116, user 0.114, sys 0.001, user+sys 0.115, 99.1 % CPU > Time for "DWARF finalize worker": wall 15.504, user 10.265, sys 4.293, user+sys 14.558, 93.9 % CPU > Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU > Time for "DWARF finalize worker": wall 15.770, user 10.372, sys 4.360, user+sys 14.732, 93.4 % CPU > Time for "DWARF finalize worker": wall 16.329, user 10.965, sys 4.415, user+sys 15.380, 94.2 % CPU > Time for "DWARF finalize worker": wall 68.077, user 33.268, sys 26.932, user+sys 60.200, 88.4 % CPU > Time for "DWARF finalize worker": wall 70.295, user 34.154, sys 27.911, user+sys 62.065, 88.3 % CPU > Time for "DWARF finalize worker": wall 73.817, user 37.446, sys 28.763, user+sys 66.209, 89.7 % CPU > Time for "DWARF finalize worker": wall 73.916, user 37.227, sys 28.555, user+sys 65.782, 89.0 % CPU > Time for "DWARF finalize worker": wall 74.662, user 37.951, sys 28.837, user+sys 66.788, 89.5 % CPU And is this with or without compiler optimizations? I have the feeling that C++ without optimizations (especially the standard lib) is slow, because you have a ton of layers of functions that would normally get optimized out, but are there in a -O0 build. > Tom, sorry for sending you on a wild goose chase. > > This patch is clearly not needed. If you have a particularly slow build, what you can do is use a local timeout factor when testing: $ echo 'set gdb_test_timeout [expr 5 * $timeout]' >> testsuite/site.exp On the other hand if the same single test often times out in a lot of scenarios or for a lot of people, then it could make sense to increase the timeout for that one in particular. Simon