Gmon File

[Lawana Stuckert]

Compileda C++ program using gcc -pg -g (at least, those are the args I gave in the Makefile; don't have any hard evidence of what command was executed). Program ran to normal completion with CWD set to my home directory. No gmon.out file written.

My program was launched by a hand-rolled Perl daemon using fork/exec. I've verified that the CWD is my home directory, and that it's writeable, by having the daemon execute touch foo just before exec'ing my target program. As far as I've been able to research, this shouldn't have affected the program's profiling or writing gmon.out when it terminated (normally).

Most of the symbols discussed in this section are defined in the headersys/gmon.h. However, some symbols (for example mcount)are not defined in any header file, since they are only intended to becalled from code generated by the compiler.

The heuristic for sizing the call graph buffer is known to beinsufficient for small programs; hence, the calculated value is clampedto be at least a minimum size. The default minimum (in units ofcall graph entries, struct tostruct), is given by the macroMINARCS. If you have some program with an unusually complexcall graph, for which the heuristic fails to allocate enough space,you can use this tunable to increase the minimum to a larger value.

To prevent excessive memory consumption when profiling very largeprograms, the call graph buffer is allowed to have a maximum ofMAXARCS entries. For some very large programs, the defaultvalue of MAXARCS defined in sys/gmon.h is too small; inthat case, you can use this tunable to increase it.

Note the value of the maxarcs tunable must be greater or equalto that of the minarcs tunable; if this constraint is violated,a warning will printed to standard error at program startup, andthe minarcs value will be used as the maximum as well.

Setting either tunable too high may result in a call graph bufferwhose size exceeds the available memory; in that case, an out of memoryerror will be printed at program startup, the profiler will bedisabled, and no gmon.out file will be generated.

Gprof is a compiler-assisted performance profiler for C, Fortran, and Pascal applications running on Unix systems. You can use Gprof to help identify hotspots in your application where code optimization efforts may be most useful.

For MPI applications, if you use the Intel MPI library, no additional steps are required before you run your code. However, if you use the HPE MPT library, you also need to set the MPI_SHEPHERD variable as follows before you run the code; otherwise, the timing information will not be shown:

Each MPI process will generate a profile with the same filename, gmon.out. These files will overwrite one another when they are written to a global filesystem. Therefore, to avoid this behavior and produce a profile with a distinct filename for each process, do:

This operation will generate a file called gmon.out.pid, where pid is the process ID of an MPI process. With N ranks, you should get N such files, with filenames differing only in their .pid extensions. You can then analyze an individual gmon.out.pid file or several at the same time.

The flat profile shows how much time your program spent in each function, and how many times that function was called. This profile helps to identify hotspots in your application. Hotspots are shown at the top of the flat profile.

The call graph shows, for each function, which functions called it; which other functions it called; and how many times the calls occurred. The call graph also provides an estimate of how much time was spent in the subroutines of each function, which can suggest places where you might try to eliminate function calls that use a lot of time.

Executing the ProgramOnce the program is compiled for profiling, you must run it in order togenerate the information that gprof needs. Simply run the programas usual, using the normal arguments, file names, etc. The program shouldrun normally, producing the same output as usual. It will, however, runsomewhat slower than normal because of the time spent collecting and thewriting the profile data.

The way you run the program--the arguments and input that you giveit--may have a dramatic effect on what the profile information shows. Theprofile data will describe the parts of the program that were activated forthe particular input you use. For example, if the first command you giveto your program is to quit, the profile data will show the time used ininitialization and in cleanup, but not much else.

Your program will write the profile data into a file called `gmon.out'just before exiting. If there is already a file called `gmon.out',its contents are overwritten. There is currently no way to tell theprogram to write the profile data under a different name, but you can renamethe file afterward if you are concerned that it may be overwritten.

In order to write the `gmon.out' file properly, your program must exitnormally: by returning from main or by calling exit. Callingthe low-level function _exit does not write the profile data, andneither does abnormal termination due to an unhandled signal.

The `gmon.out' file is written in the program's current workingdirectory at the time it exits. This means that if your program callschdir, the `gmon.out' file will be left in the last directoryyour program chdir'd to. If you don't have permission to write inthis directory, the file is not written, and you will get an error message.

Older versions of the GNU profiling library may also write a filecalled `bb.out'. This file, if present, contains an human-readablelisting of the basic-block execution counts. Unfortunately, theappearance of a human-readable `bb.out' means the basic-blockcounts didn't get written into `gmon.out'.The Perl script bbconv.pl, included with the gprofsource distribution, will convert a `bb.out' file intoa format readable by gprof.

I hope you are using gprof correctly.

After the executable is run, the gmon.out file is created.

Then you have to run "gprof.exe " and not "gprof gmon.out".

I made this mistake earlier when i tried profiling. Hope it helps.

A vulnerability was found in GNU C Library 2.38 (Software Library). It has been declared as problematic. This vulnerability affects the function __monstartup of the file gmon.c of the component Call Graph Monitor. The manipulation with an unknown input leads to a buffer overflow vulnerability. The CWE definition for the vulnerability is CWE-120. The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. As an impact it is known to affect confidentiality, integrity, and availability. CVE summarizes:

** DISPUTED ** A vulnerability was found in GNU C Library 2.38. It has been declared as critical. This vulnerability affects the function __monstartup of the file gmon.c of the component Call Graph Monitor. The manipulation leads to buffer overflow. It is recommended to apply a patch to fix this issue. VDB-220246 is the identifier assigned to this vulnerability. NOTE: The real existence of this vulnerability is still doubted at the moment. The inputs that induce this vulnerability are basically addresses of the running application that is built with gmon enabled. It's basically trusted input or input that needs an actual security flaw to be compromised or controlled.

The weakness was released 02/06/2023 by Leo Yuriev as Bug 29444 as confirmed bug report. The advisory is available at sourceware.org. This vulnerability was named CVE-2023-0687. Local access is required to approach this attack. Technical details are known, but there is no available exploit.

The real existence of this vulnerability is still doubted at the moment. The inputs that induce this vulnerability are basically addresses of the running application that is built with gmon enabled. It's basically trusted input or input that needs an actual security flaw to be compromised or controlled.

Are those some commands for bash Linux?it is loading .so libraries then some functions, is it possible to understand the loading sequence? why the gmon_start is first? why is it loading a few libraries first then call function and only then load another libries?

You seem to have some sort of executable file. There is a package on Debian (and probably other Distros) call bin-utils. It has tools for interpreting the content of this type of file. The default version on your system, will probably only work with files for the same architecture of your OS/hardware. But you can get versions for many other architectures, and maybe a version that does them all.

The GNU compiler toolset has a profiler "gprof" for performance analysis of C++ programs. With the -pg switch, the gcc compiler will make executables that write a data file, "gmon.out", on each run. This can then be fed into the gprof tool for analysis.

Usually I can decode the abbreviation or acronym to which these command-line tools refer. For example, "gprof" seems to stand for the "GNU profiler". However, I'm coming up empty for an explanation on what the token "gmon" means.

The monitor() function is a low level interface to the profil() systemcall. The lowpc and highpc parameters are the addresses of twofunctions in a program that delimit the text range to profile. Ifthe lowpc parameter is 0 (zero), the monitor() function stopsprofiling and writes out the data output file mon.out. The bufferallocated must be one-half the size of the text range to be sampled.

3a8082e126