Boost logo

Boost :

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


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

Adam Romanek


Boost list run by bdawes at, gregod at, cpdaniel at, john at