Question about valgrind suppression option

ROOT
1

Hello,

I would like to have a questions regard to the suppression valgrind report on the ROOT class.

I create a test code as follow:

#include <cstdio>
#include <cstdlib>
#include <TFile.h>

int* create_ptr( int size )
{
	int* ptr = (int*)malloc( size*sizeof(int) );
	return ptr;
}

int main( void )
{
	TFile* file = TFile::Open( "afile.root", "recreate" );
	int* ptr1 = create_ptr( 5 );
	int* ptr2 = (int*)malloc( 10*sizeof(int) );
	free( ptr1 );
	free( ptr2 );
	file -> Close( );
	delete file;
	return 0;
}

I compiled my code with:

g++ -g -o mem-leak mem-leak.C `root-config --libs --cflags`

and run the memory test with:

valgrind --num-calller=30 -suppressions=$ROOTSYS/etc/valgrind-root.supp ./mem-leak

as suggested on several topics, for example this one.
I expected that valgrind should show no memory leak as I deleted/freed all heap memory, but I still got leak reported.

==356921== Memcheck, a memory error detector
==356921== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==356921== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==356921== Command: ./mem-leak
==356921== 
==356921== 
==356921== HEAP SUMMARY:
==356921==     in use at exit: 11,833,202 bytes in 16,312 blocks
==356921==   total heap usage: 210,338 allocs, 194,026 frees, 114,836,210 bytes allocated
==356921== 
==356921== LEAK SUMMARY:
==356921==    definitely lost: 0 bytes in 0 blocks
==356921==    indirectly lost: 0 bytes in 0 blocks
==356921==      possibly lost: 0 bytes in 0 blocks
==356921==    still reachable: 11,788,018 bytes in 15,683 blocks
==356921==         suppressed: 45,184 bytes in 629 blocks
==356921== Rerun with --leak-check=full to see details of leaked memory
==356921== 
==356921== For lists of detected and suppressed errors, rerun with: -s
==356921== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 102 from 6)

Did I run the valgrind command correctly? If not, how to correct it?

Thank you very much.

ROOT Version: 6.24
Platform: CentOS 7
Compiler: g++ std=c++11

2

Hi,
this can be useful: c - Valgrind: Still Reachable Leak detected by Valgrind - Stack Overflow

1 Like
3

Thank you, the explanation is very clear. However, I still don’t know how to require valgrind to report only the real type of leak.

4

Most likely, the suppression file is missing some items for your environment. Run with

to see more information and (at least at first) generate your own suppressions to be used “in addition” to the one provided in the ROOT distribution.

1 Like
5

hello @pcanal I’m not sure if I’m doing correctly.

What I am trying is:
run valgrind with only --leak-check=full option and get a log file.

valgrind --leak-check=full ./mem-leak &> leak-check.full

I also run valgrind with --leak-check=full and --gen-suppressions=all to generate a supp file.

valgrind --leak-check=full --gen-suppressions=all ./mem-leak &> leak-check-with-supp.log

cat leak-check-with-supp.log | grep -v ^== > test.supp

I then try the use the suppression with the newly generated test.supp

valgrind --num-callers=30 --suppressions=test.supp ./mem-leak &> leak-check.log

but I still get the memory leak reported.

6

I was recommending:

valgrind --leak-check=full -suppressions=$ROOTSYS/etc/valgrind-root.supp ./mem-leak &> leak-check.full`

but I still get the memory leak reported.

That is weird. The procedure you followed should have lead to a complete removal of all the reports. The issue is possibly an issue with valgrind itself.

7

Hi @pcanal

I’ve tested with several versions of valgrind, one on my laptop (v3.18.1), one on my university server (v3.15.0) and one on lxplus (v3.22.0).
I generated the supp files using the steps I mentioned in my previous post.

I attached the final log files from different valgrind versions. Could you please take a look to see if the valgrind reports are expected.

postsupp_report-v3_15_0.txt (59.4 KB)
postsupp_report-v3_18_1.txt (977 Bytes)
postsupp_report-v3_22_0.txt (1.1 KB)

8

If I read correctedly, all 3 reports something along the line of:

==119099== LEAK SUMMARY:
==119099==    definitely lost: 0 bytes in 0 blocks
==119099==    indirectly lost: 0 bytes in 0 blocks
==119099==      possibly lost: 0 bytes in 0 blocks
==119099==    still reachable: 33,268,305 bytes in 28,333 blocks

which is the expected results (no leaks, just things that are intentionally not deleted).

The oldest version (3.15) has trouble with TStorage::UpdateIsOnHeap which is properly suppressed in the newer versions.

9

Thank you very much for clarifying. I thought that using the suppression would yield a no leak report but I was wrong. I understand how valgrind work now.

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.