What steps will reproduce the problem?
Just load and then unload the library without actually using it.
This can be achieved by either one of the following procedures:
1. Use load-time linking by linking your VS solution to the import lib. Include
any TessBaseAPI function call in your sources without actually calling it, eg
in an unused function.
2. Use run-time linking like this:
HMODULE dll = LoadLibrary(_T("libtesseract302d.dll"));
if (dll) {
while(FreeLibrary(dll));
}
2b. Repeat the code from (2) for additional memory leaks.
What is the expected output? What do you see instead?
Expected: Proper cleanup of allocated ressources.
Observation: No cleanup, instead 5 memory leaks for every load/unload cycle.
Apparently some stuff is allocated in DllMain on ATTACH, but not freed on
DETACH. Setting allocation breakpoints tells me the memory is leaked from
GetFeaturesForBlob(), but I'm not sure if this is reliable.
What version of the product are you using? On what operating system?
libtesseract302d.dll
tesseract::TessBaseAPI::Version() -> "3.02"
MSVS2008
MS Windows 7
Please provide any additional information below.
I've looked through the comments on the other memory leak bugs here and I'm
horrified. Please don't tell me "it's not a leak because it's static" or
"because the leak is outside main" or even "we new'd the static variable
because this solves the static initialization order fiasco". *shivers*
Original issue reported on code.google.com by HoneyPum...@gmail.com on 22 Oct 2014 at 11:15
Original issue reported on code.google.com by
HoneyPum...@gmail.com
on 22 Oct 2014 at 11:15