From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5FD98385828D; Fri, 28 Apr 2023 14:35:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5FD98385828D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1682692523; bh=ooPTzF/LMI6vHjDxYa+vyji6RobfztcfA3/OUyIuGwo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MrgY9R1YMQjTt/NkmgRqaAiDWZSqEEZxxZ4N1dFX7gEYc4kyJMkuEWsnMVSp15pBU QnnDUlLpErRm1mZXEn3H2BqVQgzWWJ2AMv+uVdEs5jbXB7nCE4WFYf7ZzaPwyRlyUa tnAm0yCx69T6LRJSIKQbVovqaCRjG+7UqhbQQWZU= From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug libc/27576] gmon.out not consistently created Date: Fri, 28 Apr 2023 14:35:23 +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: cvs-commit at gcc dot gnu.org 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: 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 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The release/2.36/master branch has been updated by Florian Weimer : https://sourceware.org/git/gitweb.cgi?p=3Dglibc.git;h=3D8920855c4568fa99c67= cb1c7d6b29465c25f51c2 commit 8920855c4568fa99c67cb1c7d6b29465c25f51c2 Author: Simon Kissane Date: Sat Feb 11 20:12:13 2023 +1100 gmon: improve mcount overflow handling [BZ# 27576] When mcount overflows, no gmon.out file is generated, but no message is printed to the user, leaving the user with no idea why, and thinking maybe ther= e is some bug - which is how BZ 27576 ended up being logged. Print a message= to stderr in this case so the user knows what is going on. As a comment in sys/gmon.h acknowledges, the hardcoded MAXARCS value is= too small for some large applications, including the test case in that BZ. Rather than increase it, add tunables to enable MINARCS and MAXARCS to be overridden at runtime (glibc.gmon.minarcs and glibc.gmon.maxarcs). So if a user ge= ts the mcount overflow error, they can try increasing maxarcs (they might need= to increase minarcs too if the heuristic is wrong in their case.) Note setting minarcs/maxarcs too large can cause monstartup to fail wit= h an out of memory error. If you set them large enough, it can cause an inte= ger overflow in calculating the buffer size. I haven't done anything to def= end against that - it would not generally be a security vulnerability, since these tunables will be ignored in suid/sgid programs (due to the SXID_ERASE default), and if you can set GLIBC_TUNABLES in the environment of a process, you = can take it over anyway (LD_PRELOAD, LD_LIBRARY_PATH, etc). I thought about modifying the code of monstartup to defend against integer overflows, but doing s= o is complicated, and I realise the existing code is susceptible to them even prior to this change (e.g. try passing a pathologically large highpc argument= to monstartup), so I decided just to leave that possibility in-place. Add a test case which demonstrates mcount overflow and the tunables. Document the new tunables in the manual. Signed-off-by: Simon Kissane Reviewed-by: DJ Delorie (cherry picked from commit 31be941e4367c001b2009308839db5c67bf9dcbc) --=20 You are receiving this mail because: You are on the CC list for the bug.=