Hi, Petr, I see a raw pointer named pname in ibis::part::init that is allocated with new []. Just replace it with std::string. Please take a look at SVN 531 to see if it removes the memory leak problem.
Thanks. John On 7/30/12 8:33 AM, Petr Kramolis wrote: > Hey there > > i work with the fastbit library and everything works fine but i can't > solve one memory leak. I store data in multiple directories (multiple > tables) and sometimes i call a function to build indexes (so i don't > have to build all indexes at query time). > Its really short function: > > index_table = ibis::table::create(dir.c_str()); > index_table->buildIndexes(); > delete index_table; > > and at this point valgrind reports me memory leak: > > ==16727== 128 bytes in 2 blocks are definitely lost in loss record 7 of 14 > ==16727== at 0x4C25D99: operator new[](unsigned long) (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==16727== by 0x67B62BC: ibis::part::init(char const*) (in > /usr/lib64/libfastbit.so.0.0.9) > ==16727== by 0x67B8510: ibis::part::part(char const*, bool) (in > /usr/lib64/libfastbit.so.0.0.9) > ==16727== by 0x67B8661: > ibis::util::gatherParts(std::vector<ibis::part*, > std::allocator<ibis::part*> >&, char const*, bool) (in > /usr/lib64/libfastbit.so.0.0.9) > ==16727== by 0x76B35F1: ibis::mensa::mensa(char const*) (in > /usr/lib64/libfastbit.so.0.0.9) > ==16727== by 0x76B36C8: ibis::table::create(char const*) (in > /usr/lib64/libfastbit.so.0.0.9) > ==16727== by 0x63A012B: storage_close (in > /usr/lib64/ipfixcol-fastbit-output.so) > ==16727== by 0x40395A: data_manager_free (in > /home/kramolis/git/ipfixcol/base/src/ipfixcol) > ==16727== by 0x404A6A: data_manager_close (in > /home/kramolis/git/ipfixcol/base/src/ipfixcol) > ==16727== by 0x4062D6: preprocessor_close (in > /home/kramolis/git/ipfixcol/base/src/ipfixcol) > ==16727== by 0x406014: main (in > /home/kramolis/git/ipfixcol/base/src/ipfixcol) > > can it be memory leak cased by ibis:table and its destructor? (i tried > to free created parts manually but it seams that they are freed in > destructor) > Thanks for any hits > > Petr K. > > > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
