[Bug libc/27576] gmon.out not consistently created

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27576

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The release/2.35/master branch has been updated by Florian Weimer
<fw@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9f81b8fa65798233dff2794ff0d8d2d5d8062e8b

commit 9f81b8fa65798233dff2794ff0d8d2d5d8062e8b
Author: Simon Kissane <skissane@gmail.com>
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 there 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 gets
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 with an
    out of memory error. If you set them large enough, it can cause an integer
    overflow in calculating the buffer size. I haven't done anything to defend
    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 so 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 <skissane@gmail.com>
    Reviewed-by: DJ Delorie <dj@redhat.com>
    (cherry picked from commit 31be941e4367c001b2009308839db5c67bf9dcbc)

-- 
You are receiving this mail because:
You are on the CC list for the bug.