[boost] [unordered] valgrind reports "possibly lost" memory when not destroying the container

Subject: [boost] [unordered] valgrind reports "possibly lost" memory when not destroying the container
From: Adam Romanek (romanek.adam_at_[hidden])
Date: 2014-07-04 02:18:30

Hi!

I have a problem with containers from Boost.Unordered. Before I go into 
details please let me show you the big picture.

I have a code that creates "unordered" containers in a lot of places, 
but these containers never really get destroyed / deleted at the end of 
the program. However, they are all "still reachable" through various 
pointers in the program and... valgrind reports them as such. This is OK 
for me.

Now the problem is that the containers from Boost.Unordered do something 
clever with pointers and valgrind also reports some "possibly lost" 
memory blocks [1]. This only happens when the unordered containers are 
not destroyed before the end of the program. When I do the proper 
clean-up valgrind stays quiet. However, in the code base where I 
discovered the problem it is currently not possible to do such a clean-up.

The problem became serious for me for a number of reasons. In the code 
base that I referred to above valgrind reports ~7000 "possibly lost" 
memory blocks. Some of them come from Boost.Unordered containers. I 
could try to suppress them via a suppressions file, but the problem is 
that the Boost.Unordered code gets inlined in nearly all cases and 
there's no simple way to suppress valgrind from reporting these 
"possibly lost" memory blocks. Without that I'm stuck with tons of 
reports that I can't really do anything about.

Given the above I have a few questions:
- has anyone ever encountered this problem? has anyone solved it?
- is it possible to force some simpler but maybe more expensive memory 
management in Boost.Unordered to suppress these "possibly lost" reports?
- what other options do I have?

My setup is:
- gcc 4.8.2
- Boost 1.55
- Ubuntu 14.04 x86_64

WBR,
Adam Romanek

[1] http://pastebin.com/A4fvx0K0