From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BD4D63857354; Thu, 14 Sep 2023 18:34:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD4D63857354 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1694716458; bh=xRXYyLwF+hImIM2475g4l/14Fe0j7hZnjR0ppv7a6bU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ACRUrkRl9Ujj1ydPkHQrdHoiZS+O45AiQ1aanDJ25AvbFd0WfUJBpKulNVlFoIAVr n2XuQTdyZAv0qRboooX66xPG1wRRUE/He4J4ZnJ0cy2U2/kkk1RrOKJBIjog7UdPUD UoSz8EUdphw+Vbn3JSCnBHupWJpzXZkYYbJt3mx0= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug exp/30817] [gdb/exp] Different interpretation of print options between C and Fortran Date: Thu, 14 Sep 2023 18:34:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: exp X-Bugzilla-Version: HEAD 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=3D30817 --- Comment #1 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=3D265687478be8= b9ca7e54d5eca1277a7853c36a0a commit 265687478be8b9ca7e54d5eca1277a7853c36a0a Author: Tom de Vries Date: Thu Sep 14 20:34:00 2023 +0200 [gdb/exp] Clean up asap in value_print_array_elements I've been running the test-suite on an i686-linux laptop with 1GB of memory, and 1 GB of swap, and noticed problems after running gdb.base/huge.exp:= gdb not being able to spawn for a large number of test-cases afterwards. So I investigated the memory usage, on my usual x86_64-linux development platform. The test-case is compiled with -DCRASH_GDB=3D2097152, so this: ... static int a[CRASH_GDB], b[CRASH_GDB]; ... with sizeof (int) =3D=3D 4 represents two arrays of 8MB each. Say we add a loop around the "print a" command and print space usage statistics: ... gdb_test "maint set per-command space on" for {set i 0} {$i < 100} {incr i} { gdb_test "print a" } ... This gets us: ... (gdb) print a^M $1 =3D {0 }^M Space used: 478248960 (+469356544 for this command)^M (gdb) print a^M $2 =3D {0 }^M Space used: 486629376 (+8380416 for this command)^M (gdb) print a^M $3 =3D {0 }^M Space used: 495009792 (+8380416 for this command)^M ... (gdb) print a^M $100 =3D {0 }^M Space used: 1308721152 (+8380416 for this command)^M ... In other words, we start out at 8MB, and the first print costs us about 469MB, and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the i686-linux laptop, the first print costs us 335MB. ] The subsequent 8MBs are consistent with the values being saved into the value history, but the usage for the initial print seems somewhat excessive. There is a PR open about needing sparse representation of large arrays (PR8819), but this memory usage points to an independent problem. The function value_print_array_elements contains a scoped_value_mark to free allocated values in the outer loop, but it doesn't prevent the inner lo= op from allocating a lot of values. Fix this by adding a scoped_value_mark in the inner loop, after which we have: ... (gdb) print a^M $1 =3D {0 }^M Space used: 8892416 (+0 for this command)^M (gdb) print a^M $2 =3D {0 }^M Space used: 8892416 (+0 for this command)^M (gdb) print a^M $3 =3D {0 }^M Space used: 8892416 (+0 for this command)^M ... (gdb) print a^M $100 =3D {0 }^M Space used: 8892416 (+0 for this command)^M ... Note that the +0 here just means that the mallocs did not trigger an sb= rk. This is dependent on malloc (which can use either mmap or sbrk or some pre-allocated memory) and will likely vary between different tunings, versions and implementations, so this does not give us a reliable way detect the problem in a minimal way. A more reliable way of detecting the problem is: ... void value_free_to_mark (const struct value *mark) { + size_t before =3D all_values.size (); auto iter =3D std::find (all_values.begin (), all_values.end (), mar= k); if (iter =3D=3D all_values.end ()) all_values.clear (); else all_values.erase (iter + 1, all_values.end ()); + size_t after =3D all_values.size (); + if (before - after >=3D 1024) + fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after); ... which without the fix tells us: ... +print a value_free_to_mark freed 2097152 items $1 =3D {0 } ... Fix a similar problem for Fortran: ... +print array1 value_free_to_mark freed 4194303 items $1 =3D (0, ) ... in fortran_array_printer_impl::process_element. The problem also exists for Ada: ... +print Arr value_free_to_mark freed 2097152 items $1 =3D (0 ) ... but is fixed by the fix for C. Add Fortran and Ada variants of the test-case. The *.exp files are sim= ilar enough to the original to keep the copyright years range. While writing the Fortran test-case, I ran into needing an additional p= rint setting to print the entire array in repeat form, filed as PR exp/30817. I managed to apply the compilation loop for the Ada variant as well, but with a cumbersome repetition style. I noticed no other test-case uses gnate= D, so perhaps there's a better way of implementing this. The regression test included in the patch is formulated in its weakest form, to avoid false positive FAILs, which also means that smaller regressions may not get detected. Tested on x86_64-linux. Approved-By: Tom Tromey --=20 You are receiving this mail because: You are on the CC list for the bug.=