From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D73823858428; Fri, 10 Feb 2023 10:56:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D73823858428 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676026606; bh=7z1Yn9QOlWlWMFbtszRH03uYTCENjYeZAoRK1agKp1I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lDWgJsArKjGQXJZX6z47qNO8m3oF9PuRjjEjxbD25WQHdjOPw6vLuWAabfzB+nzwl crte/AkOQjr6aZjhT0G8Be9h+6yjH6pyNEQipjxSnyR2JdHciKdBbIbxJNdZForhw6 xT57qhycTX0ZNDNJNZM0Oh7mqfkYiRY3Vu+fWxNM= From: "skissane at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/27576] gmon.out not consistently created Date: Fri, 10 Feb 2023 10:56:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: skissane at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: cc 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=3D27576 Simon Kissane changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |skissane at gmail dot com --- Comment #3 from Simon Kissane --- I'm pretty sure this is an overflow in mcount. Here's how I can tell: $ gdb ./Vt_case_huge_prof=20 GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./Vt_case_huge_prof... (No debugging symbols found in ./Vt_case_huge_prof) (gdb) break _mcleanup Function "_mcleanup" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_mcleanup) pending. (gdb) run Starting program: /home/skissane/bz27576/case/Vt_case_huge_prof=20 - t/t_case_huge.v:206: Verilog $finish Breakpoint 1, _mcleanup () at gmon.c:440 440 gmon.c: No such file or directory. (gdb) print _gmonparam $1 =3D {state =3D 2, kcount =3D 0x7ffff7972a98, kcountsize =3D 508200, from= s =3D 0x7ffff79eebc0, fromssize =3D 508194, tos =3D 0x7ffff78c0010, tossize =3D 7= 31784, tolimit =3D 30491, lowpc =3D 93824992247264,=20 highpc =3D 93824993263652, textsize =3D 1016388, hashfraction =3D 2, log_hashfraction =3D 4} Note that state=3D2. If you look at /usr/include/sys/gmon.h you will see: #define GMON_PROF_ERROR 2 So, what has happened, is gmon has gone into error state. Per the source code, only two ways this can happen: 1) monstartup runs out of memory - not case here since then tos will be NUL= L, but tos is non-NULL 2) overflow in mcount So clearly this is an overflow in mcount. There is too much profiling data = and mcount runs out of space in its buffer to store it. Probably the reason why changing compilation options around optimisation/etc makes the issue go awa= y, is that changes how the code is laid out (how many functions are called vs inlined etc) which causes less consumption of space in the buffer. Contrary to the comment by "account removed" (who I understand is someone w= ho had their Bugzilla access revoked due to unpleasant behaviour), I don't bel= ieve this is related to bug 29444. That bug complains that kcountsize and fromsi= ze are calculated incorrectly, causing a buffer overflow. Even if that's true,= the overflow condition is based on exceeding tolimit, and the patch for that bug isn't changing the calculation of tolimit. One problem here, is mcount doesn't print any error message when the overfl= ow happens, leaving the user confused as to what went wrong, as has happened in this case. Another problem, is that there is no way to increase the buffer size beyond MAXARCS entries without recompiling glibc. If MAXARCS (and maybe MINARCS to= o, in case the buffer sizing heuristic is malfunctioning) were tunables, the u= ser could respond to the overflow error message (were it printed) by increasing that tunable. --=20 You are receiving this mail because: You are on the CC list for the bug.=