memory allocated for default env is not deallocated

[cmumford]

Original issue 107 created by gsai2007 on 2012-07-27T00:38:43.000Z:

What steps will reproduce the problem?

1. create db
2. delete db
3. run the program using valgrind.

Options options_;
options_.create_if_missing = true;
options_.block_cache = cache_; // uses the default
options_.write_buffer_size = 0;
Status s = DB::Open(options_, dbRoot, &db_);
delete db_;

What is the expected output? What do you see instead?

Expected no memory leak.

==605== 512 bytes in 1 blocks are still reachable in loss record 11 of 13
==605== at 0x4C274B4: operator new(unsigned long) (vg_replace_malloc.c:287)
==605== by 0x79836C2: leveldb::InitDefaultEnv() (in /usr/local/maui/lib/libleveldb.so.1)
==605== by 0x8968B52: pthread_once (in /lib64/libpthread-2.11.1.so)
==605== by 0x7982A26: leveldb::Env::Default() (in /usr/local/maui/lib/libleveldb.so.1)
==605== by 0x7985FFC: leveldb::Options::Options() (in /usr/local/maui/lib/libleveldb.so.1)
==605== by 0x4EAFBB1: KVStoreStage::KVStoreStage(char const_) (kvstorestage.cxx:44)
==605== by 0x4EAFCFF: KVStoreStage::makeStage(std::string const&, Properties_) (kvstorestage.cxx:252)
==605== by 0x5658525: ClassFactory<Stage>::makeInstance(std::string const&, Properties*) (classfactory.hxx:150)
==605== by 0x5656945: SedaConfig::instantiate() (sedaconfig.cxx:334)
==605== by 0x5658388: SedaConfig::init() (sedaconfig.cxx:215)
==605== by 0x464259: main (kvs.cxx:120)

env.h
class Env {
public:
Env() { }
virtual ~Env();

// Return a default environment suitable for the current operating
// system. Sophisticated users may wish to provide their own Env
// implementation instead of relying on this default environment.
//
// The result of Default() belongs to leveldb and must never be deleted.
static Env* Default();

What version of the product are you using? On what operating system?

1.5.0, OS Suse Linux 11

Please provide any additional information below.

[cmumford]

Comment #1 originally posted by sanjay@google.com on 2012-07-27T22:38:40.000Z:

This is intentional so that leveldb can be used in programs that contain threads that are active while the process is exit-ing. If we attempted to clean up the default Env, we would end up causing problems for background threads.

My recommendation is to use valgrind to report only non-reachable memory, and ignore or suppress any warnings related to reachable memory.

Also, see the answers to:

http://stackoverflow.com/questions/3840582/still-reachable-leak-detected-by-valgrind