Closed alecmus closed 11 years ago
The remedy I proposed above seems to be flawed. After this adjustment the program crashes "randomly" on compression/decompression cycles.
Anyone who can offer a better solution to this issue?
Hi alecmus. Thanks for the report. I'll investigate this problem.
I'm testing following solution.
Replace this break
with following code:
if(0 == readSize) {
delete src; // fix issue #18
break;
}
lz4mtDecompress()
has same pattern, same memory leak.Lz4Mt::MemPool::alloc()
.break
without delete
or passing src
to f()
.To solve this problem, insert delete src;
to line 712 and line 720.
Since these break
s handle error case, maybe you've not seen memory leak in lz4mtDecompress()
.
src
is (almost) always delete
d.This BufferPtr
is std::unique_ptr
.
So the src
which is passed to f()
will be always delete
d.
Firstly, delete src
at end of for
loop seems good.
But src
is passed to f()
with std::async()
, so your proposal may delete src
before f()
will be done all procedure.
delete
d ?This break
makes a bad code path.
In this branch, src
is not delete
d.
Lz4Mt::MemPool::alloc()
.Thanks for your effort. Hadn't actually noticed this break in 477. After a short look it's clear that is exactly where src is left 'undeleted'. And indeed hadn't noticed the potential leak in lz4mtDecompress(). Also testing the solution you've proposed.
There is a memory leak caused by lz4mt.cpp. It is caused by the assignment of dynamic memory in line 471:
auto src = srcBufferPool.alloc();
Each time the loop runs this memory is not freed.
Discovered the memory leak using the CRT Debug Library: _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
Pinpointed the source to the location using Visual Leak Detector (http://vld.codeplex.com/).
Suggested solution:
No memory leak detected after this adjustment.