|
From: Bresalier, R. (N. - US/M. Hill) <rob...@no...> - 2022-07-13 20:12:02
|
We are trying to track down a suspected place in our code that keeps accumulating memory in a 'still reachable'. When I turn on still reachable and run my process for a few hours and then stop the process to get the valgrind reports there are over 2.7 million loss records which are mostly still reachables. It would take forever for valgrind to print this out. The large majority of "still reachable" that I want to ignore allocate just a few blocks. I would like to suppress these and only output "still reachables" that allocated 100 blocks or more. The suppression mechanism seems to only be to suppress particular backtraces. But I would like to suppress based on number of blocks instead, suppress loss records with a small number of blocks. Is this possible to suppress based on block count without patching valgrind? If not possible without patching valgrind, any hints on where I could patch valgrind to accomplish this? Thanks, Rob |
|
From: John R. <jr...@bi...> - 2022-07-14 02:13:28
|
> We are trying to track down a suspected place in our code that keeps accumulating memory in a ‘still reachable’. > > When I turn on still reachable and run my process for a few hours and then stop the process to get the valgrind reports there are over 2.7 million loss records which are mostly still reachables. It would take forever for valgrind to print this out. It would take around one hour or less to *produce* the complete report without printing it. Re-direct stderr to a file, or use command-line options --xml-fd= or --xml-file=. See "valgrind --help" and/or the user manual for other options to control error reporting. Using any text editor on the report file, or inserting the 'sed' (or 'awk') stream editor into the pipeline of error output, enables filtering the error reports. > The large majority of “still reachable” that I want to ignore allocate just a few blocks. I would like to suppress these and only output “still reachables” that allocated 100 blocks or more. Note that all the excluded reports (counts 1 through 99) have only 1 or 2 characters in their decimal representation, so you don't even need to convert the field to a number to decide. > If not possible without patching valgrind, any hints on where I could patch valgrind to accomplish this? Find the source location which prints the instance count, and adjust the code. This is "standard engineering effort" for a programmer who is adept at using 'grep', even without prior experience with the source code of valgrind. |
|
From: Julian S. <jse...@gm...> - 2022-07-14 09:51:05
|
On 13/07/2022 16:38, Bresalier, Rob (Nokia - US/Murray Hill) wrote: > We are trying to track down a suspected place in our code that keeps accumulating memory in a 'still reachable'. It sounds like you're trying to track down a "process lifetime" leak. You'd be better off using one of the heap profiling tools for that, either massif (--tool=massif) or dhat (--tool=dhat), but probably massif. You'll need to ask your package manager to install the massif-visualizer GUI. Run with --tool=massif --num-callers=12 (or 16 or whatever). Use the GUI to look at the resulting profile. After a bit of poking around it should be obvious where all your allocation is coming from. J |