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>

1 files changed, 59 insertions, 0 deletions

diff --git a/manual/tunables.texi b/manual/tunables.texi
index c2630b8..0be7231 100644
--- a/manual/tunables.texi
+++ b/manual/tunables.texi
@@ -77,6 +77,9 @@ glibc.malloc.check: 0 (min: 0, max: 3)
 				  capabilities seen by @theglibc{}
 * Memory Related Tunables::  Tunables that control the use of memory by
 			     @theglibc{}.
+* gmon Tunables::  Tunables that control the gmon profiler, used in
+                   conjunction with gprof
+
 @end menu
 
 @node Tunable names
@@ -616,3 +619,59 @@ support in the kernel if this tunable has any non-zero value.
 
 The default value is @samp{0}, which disables all memory tagging.
 @end deftp
+
+@node gmon Tunables
+@section gmon Tunables
+@cindex gmon tunables
+
+@deftp {Tunable namespace} glibc.gmon
+This tunable namespace affects the behaviour of the gmon profiler.
+gmon is a component of @theglibc{} which is normally used in
+conjunction with gprof.
+
+When GCC compiles a program with the @code{-pg} option, it instruments
+the program with calls to the @code{mcount} function, to record the
+program's call graph. At program startup, a memory buffer is allocated
+to store this call graph; the size of the buffer is calculated using a
+heuristic based on code size. If during execution, the buffer is found
+to be too small, profiling will be aborted and no @file{gmon.out} file
+will be produced. In that case, you will see the following message
+printed to standard error:
+
+@example
+mcount: call graph buffer size limit exceeded, gmon.out will not be generated
+@end example
+
+Most of the symbols discussed in this section are defined in the header
+@code{sys/gmon.h}. However, some symbols (for example @code{mcount})
+are not defined in any header file, since they are only intended to be
+called from code generated by the compiler.
+@end deftp
+
+@deftp Tunable glibc.mem.minarcs
+The heuristic for sizing the call graph buffer is known to be
+insufficient for small programs; hence, the calculated value is clamped
+to be at least a minimum size. The default minimum (in units of
+call graph entries, @code{struct tostruct}), is given by the macro
+@code{MINARCS}. If you have some program with an unusually complex
+call graph, for which the heuristic fails to allocate enough space,
+you can use this tunable to increase the minimum to a larger value.
+@end deftp
+
+@deftp Tunable glibc.mem.maxarcs
+To prevent excessive memory consumption when profiling very large
+programs, the call graph buffer is allowed to have a maximum of
+@code{MAXARCS} entries. For some very large programs, the default
+value of @code{MAXARCS} defined in @file{sys/gmon.h} is too small; in
+that case, you can use this tunable to increase it.
+
+Note the value of the @code{maxarcs} tunable must be greater or equal
+to that of the @code{minarcs} tunable; if this constraint is violated,
+a warning will printed to standard error at program startup, and
+the @code{minarcs} value will be used as the maximum as well.
+
+Setting either tunable too high may result in a call graph buffer
+whose size exceeds the available memory; in that case, an out of memory
+error will be printed at program startup, the profiler will be
+disabled, and no @file{gmon.out} file will be generated.
+@end deftp