Valgrind tool callgrind

Any appearance of it causes Valgrind to switch to producing full paths and applying the above filtering rule. Each produced path is compared against all the --fullpath-after -specified strings, in the order specified.

The first string to match causes the path to be truncated as described above. If none match, the full path is shown. This facilitates chopping off prefixes when the sources are drawn from a number of unrelated directories.

However, there may be scenarios where you may wish to put debug objects at an arbitrary location, such as external storage when running Valgrind on a mobile device with limited local storage. Another example might be a situation where you do not have permission to install debug object packages on the system where you are running Valgrind.

The given path will be prepended to the absolute path name of the searched-for object. This flag should only be specified once.

If it is specified multiple times, only the last instance is honoured. In some scenarios it may be convenient to read debuginfo from objects stored on a different machine. With this flag, Valgrind will query a debuginfo server running on ipaddr and listening on port port, if it cannot find the debuginfo object in the local filesystem. The debuginfo server must accept TCP connections on port port.

It will only serve from the directory it is started in. That in turn will look only in its current working directory for a matching debuginfo object. The debuginfo data is transmitted in small fragments 8 KB as requested by Valgrind.

Each block is compressed using LZO to reduce transmission time. The implementation has been tuned for best performance over a single-stage Note that checks for matching primary vs debug objects, using GNU debuglink CRC scheme, are performed even when using the debuginfo server.

By default the Valgrind build system will build valgrind-di-server for the target platform, which is almost certainly not what you want. This guarantees that it does not read debuginfo from out of date debuginfo objects, and also ensures that Valgrind can't crash as a result of mismatches. This may be useful when the debuginfo and main objects have not been split in the proper way. Be careful when using this, though: it disables all consistency checking, and Valgrind has been observed to crash when the main and debuginfo objects don't match.

You may use up to extra suppression files. Pressing Y Ret or y Ret causes Valgrind to write a suppression for this error. You can then cut and paste it into a suppression file if you don't want to hear about the error in the future. When set to all , Valgrind will print a suppression for every reported error, without querying the user.

Note that the suppressions printed are as specific as possible. You may want to common up similar ones, by adding wildcards to function names, and by using frame-level wildcards. The wildcarding facilities are powerful yet flexible, and with a bit of careful editing, you may be able to suppress a whole family of related errors with only a few suppressions. Sometimes two different errors are suppressed by the same suppression, in which case Valgrind will output the suppression more than once, but you only need to have one copy in your suppression file but having more than one won't cause problems.

By default it reads from the standard input stdin , which is problematic for programs which close stdin. This option allows you to specify an alternative file descriptor from which to read input. Mac OS X uses a deferred debug information debuginfo linking scheme. When object files containing debuginfo are linked into a.

Instead, the debuginfo must be linked manually by running dsymutil, a system-provided utility, on the executable or. The resulting combined debuginfo is placed in a directory alongside the executable or. In these cases, Valgrind will print a warning message but take no further action. It fails both because the debuginfo for such pre-installed system components is not available anywhere, and also because it would require write privileges in those directories.

Also note that dsymutil is quite slow, sometimes excessively so. If the stack pointer moves by more than this amount then Valgrind will assume that the program is switching to a different stack. You may need to use this option if your program has large stack-allocated arrays. Valgrind keeps track of your program's stack pointer. If it changes by more than the threshold amount, Valgrind assumes your program is switching to a different stack, and Memcheck behaves differently than it would for a stack pointer change smaller than the threshold.

Usually this heuristic works well. However, if your program allocates large structures on the stack, this heuristic will be fooled, and Memcheck will subsequently report large numbers of invalid stack accesses. This option allows you to change the threshold to a different value. You should only consider use of this option if Valgrind's debug output directs you to do so.

In that case it will tell you the new threshold you should specify. In general, allocating large structures on the stack is a bad idea, because you can easily run out of stack space, especially on systems with limited memory or which expect to support large numbers of threads each with a small stack, and also because the error checking performed by Memcheck is more effective for heap-allocated data than for stack-allocated data.

If you have to use this option, you may wish to consider rewriting your code to allocate on the heap rather than on the stack. To simplify its memory management, Valgrind reserves all required space for the main thread's stack at startup. That means it needs to know the required stack size at startup.

By default, Valgrind uses the current "ulimit" value for the stack size, or 16 MB, whichever is lower. In many cases this gives a stack size in the range 8 to 16 MB, which almost never overflows for most applications. If you need a larger total stack size, use --main-stacksize to specify it.

Only set it as high as you need, since reserving far more space than you need that is, hundreds of megabytes more than you need constrains Valgrind's memory allocators and may reduce the total amount of memory that Valgrind can use.

This is only really of significance on bit machines. On Linux, you may request a stack of size up to 2GB. Valgrind will stop with a diagnostic message if the stack cannot be allocated.

It has no bearing on the size of thread stacks, as Valgrind does not allocate those. You may need to use both --main-stacksize and --max-stackframe together.

It is important to understand that --main-stacksize sets the maximum total stack size, whilst --max-stackframe specifies the largest size of any one stack frame. You will have to work out the --main-stacksize value for yourself usually, if your applications segfaults. But Valgrind will tell you the needed --max-stackframe size, if necessary. As discussed further in the description of --max-stackframe , a requirement for a large stack is a sign of potential portability problems.

You are best advised to place all large data in heap-allocated memory. Occasionally, that number is too small. Use this option to provide a different limit. This option allows you to specify a different alignment. The supplied value must be greater than or equal to the default, less than or equal to , and must be a power of two. Such padding blocks are called redzones. The default value for the redzone size depends on the tool.

For example, Memcheck adds and protects a minimum of 16 bytes before and after each block allocated by the client. This allows it to detect block underruns or overruns of up to 16 bytes. Increasing the redzone size makes it possible to detect overruns of larger distances, but increases the amount of memory used by Valgrind. When set to none , no memory execution tree is produced. When set to allocs , the memory execution tree gives the current number of allocated bytes and the current number of allocated blocks.

When set to full , the memory execution tree gives 6 different measurements : the current number of allocated bytes and blocks same values as for allocs , the total number of allocated bytes and blocks, the total number of freed bytes and blocks. Note that the overhead in cpu and memory to produce an xtree depends on the tool. The overhead in cpu is small for the value allocs , as the information needed to produce this report is maintained in any case by the tool.

For massif and helgrind, specifying full implies to capture a stack trace for each free operation, while normally these tools only capture an allocation stack trace. The memory overhead varies between 5 and 10 words per unique stacktrace in the xtree, plus the memory needed to record the stack trace for the free operations, if needed specifically for the xtree. If the filename contains the extension. Most people won't need to use them. If no checking is done, when a program executes some code, then overwrites it with new code, and executes the new code, Valgrind will continue to execute the translations it made for the old code.

For "modern" architectures -- anything that's not x86, amd64 or sx -- the default is stack. This is because a correct program must take explicit action to reestablish D-I cache coherence following code modification.

Valgrind observes and honours such actions, with the result that self-modifying code is transparently handled with zero extra cost. For x86, amd64 and sx, the program is not required to notify the hardware of required D-I coherence syncing. Hence the default is all-non-file , which covers the normal case of generating code into an anonymous non-file-backed mmap'd area. The meanings of the four available settings are as follows. No detection none , detect self-modifying code on the stack which is used by GCC to implement nested functions stack , detect self-modifying code everywhere all , and detect self-modifying code everywhere except in file-backed mappings all-non-file.

Running with all will slow Valgrind down noticeably. Running with none will rarely speed things up, since very little code gets dynamically generated in most programs. It adds checks to any translations that do not originate from file-backed memory mappings.

Typical applications that generate code, for example JITs in web browsers, generate code into anonymous mmaped areas, whereas the "fixed" code of the browser always lives in file-backed mappings. This slows Valgrind startup and makes it use more memory typically for each inlined piece of code, 6 words and space for the function name , but it results in more descriptive stacktraces.

This slows Valgrind startup significantly and makes it use significantly more memory, but for the tools that can take advantage of it Memcheck, Helgrind, DRD it can result in more precise error messages. This activity poll will be done after having run the given number of basic blocks or slightly more than the given number of basic blocks.

This poll is quite cheap so the default value is set relatively low. You might further decrease this value if vgdb cannot use ptrace system call to interrupt Valgrind if all threads are most of the time blocked in a system call. With this, the value of the Valgrind shadow registers can be examined or changed using GDB. Exposing shadow registers only works with GDB version 7.

The prefix option controls the directory and prefix for the creation of these files. The GNU C library libc. Usually it doesn't bother to free that memory when the program ends— there would be no point, since the Linux kernel reclaims all process resources when a process exits anyway, so it would just slow things down. The glibc authors realised that this behaviour causes leak checkers, such as Valgrind, to falsely report leaks in glibc, when a leak check is done at exit.

This was particularly noticeable on Red Hat 7. Usually it doesn't bother to free that memory when the program ends—there would be no point, since the kernel reclaims all process resources when a process exits anyway, so it would just slow things down. Pass miscellaneous hints to Valgrind which slightly modify the simulated behaviour in nonstandard or dangerous ways, possibly to help the simulation of strange features.

By default no hints are enabled. Use with caution! Doesn't require the full buffer to be initialised when writing. Without this, using some device drivers with a large number of strange ioctl commands becomes very tiresome. This may be necessary when running Valgrind on a multi-threaded program that uses one thread to manage a FUSE file-system and another thread to access that file-system. The GNU glibc pthread library libpthread. When a pthread terminates, the memory used for the pthread stack and some thread local storage related data structure are not always directly released.

This memory is kept in a cache up to a certain size , and is re-used if a new thread is started. This cache causes the helgrind tool to report some false positive race condition errors on this cached memory, as helgrind does not understand the internal glibc cache synchronisation primitives.

So, when using helgrind, disabling the cache helps to avoid false positive race conditions, in particular when using thread local storage variables e. Note: Valgrind disables the cache using some internal knowledge of the glibc stack cache implementation and by examining the debug information of the pthread library.

This technique is thus somewhat fragile and might not work for all glibc versions. This has been successfully tested with various glibc versions e. Does not require that full buffer is initialised when writing. Without this, programs using libdoor 3LIB functionality with completely proprietary semantics may report large number of false positives.

The standard implementation gives more correct behaviour, but can cause indefinite looping on certain processor implementations that are intolerant of extra memory references between LL and SC. So far this is known only to happen on Cavium 3 cores. You should not need to use this flag, since the relevant cores are detected at startup and the alternative implementation is automatically enabled if necessary. There is no equivalent anti-flag: you cannot force-disable the alternative implementation, if it is automatically enabled.

The underlying problem exists because the "standard" implementation of LL and SC is done by copying through LL and SC instructions into the instrumented code. Furthermore, the L1 caches often have low associativity, so simulating them can detect cases where the code interacts badly with this cache eg.

Cachegrind gathers the following statistics abbreviations used for each statistic is given in parentheses :. I cache reads Ir , which equals the number of instructions executed , I1 cache read misses I1mr and LL cache instruction read misses ILmr. Conditional branches executed Bc and conditional branches mispredicted Bcm.

Indirect branches executed Bi and indirect branches mispredicted Bim. These statistics are presented for the entire program and for each function in the program.

You can also annotate each line of source code in the program with the counts that were caused directly by it. On a modern machine, an L1 miss will typically cost around 10 cycles, an LL miss can cost as much as cycles, and a mispredicted branch costs in the region of 10 to 30 cycles. Detailed cache and branch profiling can be very useful for understanding how your program interacts with the machine and thus how to make it faster.

Also, since one instruction cache read is performed per instruction executed, you can find out how many instructions are executed per line, which can be useful for traditional profiling. First off, as for normal Valgrind use, you probably want to compile with debugging info the -g option. But by contrast with normal Valgrind use, you probably do want to turn optimisation on, since you should profile your program as it will be normally run.

The program will execute slowly. Upon completion, summary statistics that look like this will be printed:. Cache accesses for instruction fetches are summarised first, giving the number of fetches made this is the number of instructions executed, which can be useful to know in its own right , the number of I1 misses, and the number of LL instruction LLi misses.

Cache accesses for data follow. The information is similar to that of the instruction fetches, except that the values are also shown split between reads and writes note each row's rd and wr values add up to the row's total. Combined instruction and data figures for the LL cache follow that. Note that the LL miss rate is computed relative to the total number of memory accesses, not the number of L1 misses.

Branch prediction statistics are not collected by default. As well as printing summary information, Cachegrind also writes more detailed profiling information to a file. By default this file is named cachegrind. The default. Firstly, it means you don't have to rename old log files that you don't want to overwrite.

The output file can be big, many megabytes for large applications built with full debugging information. I1 cache, D1 cache, LL cache: cache configuration. So you know the configuration with which these results were obtained. Events shown: the events shown, which is a subset of the events gathered. This can be adjusted with the --show option. Event sort order: the sort order in which functions are shown. For example, in this case the functions are sorted from highest Ir counts to lowest.

If two functions have identical Ir counts, they will then be sorted by I1mr counts, and so on. This order can be adjusted with the --sort option. Note that this dictates the order the functions appear. It is not the order in which the columns appear; that is dictated by the "events shown" line and can be changed with the --show option.

The threshold can be adjusted with the --threshold option. In this case no. If a column contains only a dot it means the function never performs that event e. The name??? If most of the entries have the form??? It is worth noting that functions will come both from the profiled program e. By default, all source code annotation is also shown. Each source file is clearly marked User-annotated source as having been chosen manually for annotation. Each line is annotated with its event counts. Events not applicable for a line are represented by a dot.

This is useful for distinguishing between an event which cannot happen, and one which can but did not. Sometimes only a small section of a source file is executed. To minimise uninteresting output, Cachegrind only shows annotated lines and lines within a small distance of annotated lines.

Gaps are marked with the line numbers so you know which part of a file the shown code comes from, eg:. The amount of context to show around annotated lines is controlled by the --context option.

Automatic annotation is enabled by default. Therefore, the files chosen for auto-annotation are affected by the --sort and --threshold options.

Each source file is clearly marked Auto-annotated source as being chosen automatically. Any files that could not be found are mentioned at the end of the output, eg:. This is quite common for library files, since libraries are usually compiled with debugging information, but the source files are often not present on a system.

If a file is chosen for annotation both manually and automatically, it is marked as User-annotated source. Also beware that auto-annotation can produce a lot of output if your program is large! Valgrind can annotate assembly code programs too, or annotate the assembly code generated for your C program. Sometimes this is useful for understanding what is really happening when an interesting line of C code is translated into multiple instructions.

To do this, you just need to assemble your. If your program forks, the child will inherit all the profiling data that has been gathered for the parent. Massif runs programs about 20x slower than normal. Helgrind is a thread debugger which finds data races in multithreaded programs. Such locations are indicative of missing synchronisation between threads, and could cause hard-to-find timing-dependent problems. It is useful for any program that uses pthreads.

It is a somewhat experimental tool, so your feedback is especially welcome here. While Helgrind can detect locking order violations, for most programs DRD needs less memory to perform its analysis. Lackey and Nulgrind are also included in the Valgrind distribution. They don't do very much, and are there for testing and demonstrative purposes.

DHAT is a tool for examining how programs use their heap allocations. It tracks the allocated blocks, and inspects every memory access to find which block, if any, it is to. It comes with a GUI to facilitate exploring the profile results. It is most easily understood using the kcachegrind GUI tool.

This reads the information produced by callgrind and creates a list of function calls along with information on timings of each of the calls during the profiled run. If the source code is available it can also show the lines of code that relate to the functions being inspected. Example of KCachegrind display a profile of MantidPlot starting up and closing down. By default KCachegrind shows the number of instructions fetched within its displays.

This can be changed using the drop-down box at the top right of the screen. The Instruction Fetch and Cycle Estimation are generally the most widely used and roughly correlate to the amount of time spent performing the displayed functions.