memory allocated for default env is not deallocated

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by gsai2...@gmail.com on 27 Jul 2012 at 12:38

[GoogleCodeExporter]

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-valg
rind

Original comment by san...@google.com on 27 Jul 2012 at 10:38

• Changed state: WontFix