Maybe this is not a good question to post but I am kinda desperate. I have a memory leak, but i don't know how to overcome it. Using valgrind find:
but i can`t find where i lost "delete" in code; Maybe someone can help me with
class TData {
public:
bool IsEmpty;
int Key;
char Value[65];
TData();
void Print();
};
class TVector {
private:
size_t capacity;
public:
TData *array;
size_t size;
TVector();
TVector(const size_t &);
size_t Size() const;
size_t Capacity() const;
void Push_back(const TData &);
void CountingSort(TVector* vector);
~TVector();
};
TData::TData() {
this->Key = 0;
}
void TData::Print() {
printf("%d\t%s\n", this->Key, this->Value);
}
TVector::TVector() {
size = 0;
capacity = 1;
array = new TData[capacity];
}
TVector::TVector(const size_t & sizeVector) {
capacity = sizeVector;
size = 0;
array = new TData[sizeVector];
}
void TVector::Push_back(const TData &temp) {
if (size == capacity) {
capacity *= 2;
TData *result = new TData[capacity];
for (int index = 0; index < size; index++) {
result[index] = array[index];
}
delete[] array;
this->array = result;
}
array[size++] = temp;
}
size_t TVector::Size() const {
return size;
}
size_t TVector::Capacity() const {
return capacity;
}
void TVector::CountingSort(TVector* vector) {
int tmp[RANGE] = { 0 };
TData *out = new TData[vector->Size()];
for (int i = 0; i < vector->Size(); i++) {
tmp[vector->array[i].Key]++;
}
for (int i = 1; i < RANGE; i++) {
tmp[i] += tmp[i - 1];
}
for (int i = vector->Size() - 1; i >= 0; i--) {
out[--tmp[vector->array[i].Key]] = vector->array[i];
}
for (int i = 0; i < vector->Size(); ++i) {
vector->array[i] = out[i];
}
delete[] out;
}
TVector::~TVector() {
delete[] array;
}
int main(void) {
TVector v;
TData data;
while (scanf("%d%s", &data.Key, data.Value) == 2) {
v.Push_back(data);
}
if (v.Size() > 1) {
v.CountingSort(&v);
}
for (int i = 0; i < v.Size(); ++i) {
printf("%d\t%s\n", v.array[i].Key, v.array[i].Value);
}
return 0;
}
I finded it when try use program with tests. I have time limit error and i thought maybe it can be memory leaks. I don't know why i didn't checked it before.
Added delete[] out
, but stil have memory leak
HEAP SUMMARY:
==4554== in use at exit: 72,704 bytes in 1 blocks
==4554== total heap usage: 3 allocs, 2 frees, 73,804 bytes allocated
==4554==
==4554== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==4554== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4554== by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4554== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==4554== by 0x40107CA: call_init (dl-init.c:30)
==4554== by 0x40107CA: _dl_init (dl-init.c:120)
==4554== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==4554==
==4554== LEAK SUMMARY:
==4554== definitely lost: 0 bytes in 0 blocks
==4554== indirectly lost: 0 bytes in 0 blocks
==4554== possibly lost: 0 bytes in 0 blocks
==4554== still reachable: 72,704 bytes in 1 blocks
==4554== suppressed: 0 bytes in 0 blocks
==4554==
==4554== For counts of detected and suppressed errors, rerun with: -v
==4554== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
我没有看到为此释放内存:
TData *out = new TData[vector->Size()];
-g
with gcc or clang).valgrind --leak-check=full a.out
.You don't have a memory leak, your outputs says that some memory was not free'd, but is still reachable :
==4554== LEAK SUMMARY:
==4554== definitely lost: 0 bytes in 0 blocks
==4554== indirectly lost: 0 bytes in 0 blocks
==4554== possibly lost: 0 bytes in 0 blocks
==4554== still reachable: 72,704 bytes in 1 blocks
==4554== suppressed: 0 bytes in 0 blocks
This is not your fault, but an issue/feature with GNU Libc. You can get more information at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
This memory is allocated as an emergency buffer for C++ exceptions for low memory situations. You can find more info here: What happens if 'throw' fails to allocate memory for exception object?
This is the code that causes this warning (see line 123): https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc
It allocates
EMERGENCY_OBJ_SIZE * EMERGENCY_OBJ_COUNT + EMERGENCY_OBJ_COUNT * sizeof (__cxa_dependent_exception)
which is equivalent of
64 * 1024 + 64 * 112 = 72704
This was done on purpose, as it doesn't really hurt if you live some memory chunk allocated before termination, so some libraries (especially low-level ones) do this, mostly to solve their issues with object lifetime in threaded environment. You may encounter the same issue with some Boost libraries too - I think either Boost.System or Boost.Filesystem always leaves 32 byte memory chunk hanging around.
You can try using smart pointers to avoid this type of problems. some info here
I would say that you have memory leak here (when you are using 'new' statement you have to remember to use 'delete' as well on the same object):
void TVector::Push_back(const TData &temp) {
if (size == capacity) {
capacity *= 2;
TData *result = new TData[capacity]; <--allocation
for (int index = 0; index < size; index++) {
result[index] = array[index];
}
delete[] array; <-- removal of 'array' it's ok but where you delete 'result' - memory allocated but never freed
this->array = result;
}
array[size++] = temp;
}
If you can't use smart pointers (std::unique_ptr, std::shared_ptr, std::weak_ptr) which are in 'memory' header(since c++11 standard) - you can create your own implementation to avoid this.
template <typename T>
class smart_ptr
{
public:
smart_ptr()
{
value = new T(0);
}
smart_ptr(T p_value)
:value(new T(p_value))
{}
T operator*()
{
return *value;
}
T* operator->()
{
return value;
}
~smart_ptr()
{
delete value;
}
private:
T *value;
};
When you will use it when your code will go out of scope of function destructor of 'smart_ptr' class will be called - will not cause memory leak. However this one is too simple - still I recommend to using 'original' smart pointers from memory header. It will be much safer :)
To detect this kind of defect in your code you can use tools like sanitizers as well: https://github.com/google/sanitizers/wiki/AddressSanitizer
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.