[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static allocations vs. memory leaks

From: Bruno Haible
Subject: Re: static allocations vs. memory leaks
Date: Sun, 16 Feb 2020 23:43:10 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

> Ideally, valgrind would have a way to distinguish static memory allocations
> from leaks (where by "leak" I mean an allocation that would accumulate when
> the code is run repeatedly). How could such a distinction be implemented,
> without multiplying the time needed to run the test by a factor of 100 or 
> 1000?
> Possibly define a function 'static_malloc' that is equivalent to 'malloc'
> in glibc, but handled differently inside valgrind?

Thinking more about it: How about a statically allocated hash table (or other
complex data structure)? We don't want to complicate the code of the hash
table with the option to choose a different allocator.

We would need primitive functions begin/end_static_allocation() that tell
valgrind to ignore the allocations between begin_static_allocation() and

And it would need to nest. Example:

   malloc (10);
   begin_static_allocation ();
   malloc (100);
   begin_static_allocation ();
   malloc (1000);
   end_static_allocation ();
   malloc (100);
   end_static_allocation ();
   malloc (1000000);

valgrind would report two memory allocations: 10 and 1000000.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]