mem leak #6
Comments
|
Verified that memory leak is fixed today |
This was referenced Aug 17, 2015
Closed
kspangsege
added a commit
that referenced
this issue
May 23, 2016
…(during DNS lookup) in util/event_loop_posix.cpp
pavel-ship-it
pushed a commit
that referenced
this issue
Jul 28, 2020
# This is the 1st commit message: Added basiс build configuration for macosx # This is the commit message #2: Fix complains on missing compilers # This is the commit message #3: It can build x86_64 # This is the commit message #4: x86_64; arm64 in a single build # This is the commit message #5: remove unused code added mergeLibs script # This is the commit message #6: Added basiс build configuration for macosx # This is the commit message #7: Fix complains on missing compilers # This is the commit message #8: It can build x86_64 # This is the commit message #9: x86_64; arm64 in a single build
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
me@ubuntu:/mnt/hgfs/D/tightdb_lasse/test/test-tightdb$ valgrind --leak-check=full ./test-tightdb
==26714== Memcheck, a memory error detector
==26714== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==26714== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==26714== Command: ./test-tightdb
==26714==
Memory usage: 99860480 bytes
Search (small integer): 32ms
Search (byte-size integer): 24ms
errorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorSearch (string): 169ms
Add index: 391ms
Memory usage2: 100028416 bytes
Search index: 8479ms
==26714==
==26714== HEAP SUMMARY:
==26714== in use at exit: 384 bytes in 1 blocks
==26714== total heap usage: 164,649 allocs, 164,648 frees, 20,650,058 bytes allocated
==26714==
==26714== 384 bytes in 1 blocks are definitely lost in loss record 1 of 1
==26714== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261)
==26714== by 0x411EE1: AdaptiveStringColumn::LeafInsert(unsigned long, char const_) (ColumnString.cpp:202)
==26714== by 0x413341: ColumnBase::NodeChange ColumnBase::DoInsert<char const_, AdaptiveStringColumn>(unsigned long, char const_) (Column_tpl.h:192)
==26714== by 0x4124FB: bool ColumnBase::TreeInsert<char const_, AdaptiveStringColumn>(unsigned long, char const_) (Column_tpl.h:82)
==26714== by 0x411B3D: AdaptiveStringColumn::Insert(unsigned long, char const_) (ColumnString.cpp:132)
==26714== by 0x41BDCC: Table::InsertString(unsigned long, unsigned long, char const_) (Table.cpp:342)
==26714== by 0x41D9DD: TestTable::Add(long, char const_, long, TypeEnum) (test-tightdb.cpp:37)
==26714== by 0x41D393: main (test-tightdb.cpp:49)
==26714==
==26714== LEAK SUMMARY:
==26714== definitely lost: 384 bytes in 1 blocks
==26714== indirectly lost: 0 bytes in 0 blocks
==26714== possibly lost: 0 bytes in 0 blocks
==26714== still reachable: 0 bytes in 0 blocks
==26714== suppressed: 0 bytes in 0 blocks
==26714==
==26714== For counts of detected and suppressed errors, rerun with: -v
==26714== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
me@ubuntu:/mnt/hgfs/D/tightdb_lasse/test/test-tightdb$
The text was updated successfully, but these errors were encountered: