[Memory leak] Windows LoadLibrary with dll linked with OpenBlas

[m3rik]

Hello,

I used openblas in a c++ plugin that is loaded using LoadLibrary in Windows. The problem is that if I load and unload the library for a thousand times, there are at least 100 MB of memory leak.

I built a small project for demo purposes.

LinkedBlas.dll - linked with OpenBlas (prebuilt binaries from sourceforge or nuget package)
TestOpenblas.exe - loads linkedblas.dll and frees the library without using anything from it.

The memory leak is present on both architectures x86 and x64.
Is there a problem that I load a library built with mingw in mcvs?

[brada4]

Somehow test case is missing in your post. Can you dump heap objects from process with leaks?

[martin-frbg]

Do you still see a memory leak when you reduce your test case to a simple

HMODULE hMod = LoadLibrary("openblas.dll");
FreeLibrary( hMod );

(Suggestion stolen from http://forums.codeguru.com/showthread.php?504479-Memory-leak-in-DLLMain )

[m3rik]

Yes. (https://i.imgur.com/CITUqVh.jpg)
And the dll called LinkedBlas.dll is linked with Openblas.

[brada4]

And directly with openblas.dll to isolate any issues with your shim library?

[m3rik]

Yes. Linkedblas.dll is linked with libopenblas.dll

[m3rik]

I've tried directly using LoadLibrary on libopenblas.dll and the memory leak is still present.

	for (int i = 0; i < 10000; i++) {
		
		HMODULE lib = LoadLibraryExA("libopenblas.dll", NULL, 0);
		if (!lib) {
			printf("Error loading lib\n");
		}
		
		BOOL ret = FreeLibrary(lib);
		if (ret) {
			printf("Done loading %d\n", i);
		}
		else {
			printf("Error freeing\n");
		}
	}

[m3rik]

Further investigations reveals:
When I set OPENBLAS_NUM_THREADS=1, the memory leak disappears.
When I set OPENBLAS_NUM_THREADS=8. the memory leak reappers.

[martin-frbg]

I have some vague recollection of there being problems with dynamic loading of libraries that then make use of thread-local storage, not sure if this is the issue here though. I assume that VS does not provide details of the loss records, but perhaps this is reproducible on Linux (doing dlopen() of libopenblas) with valgrind.

[m3rik]

Thank you very much for your help. I will try to reproduce on linux also.

[brada4]

FreeLibrary returns zero on failure, I read it on MSDN...
It is awkward, but your error handling is reverse too...

[m3rik]

The type is BOOL of the return value and I thought it makes sense to write if(ret)

[brada4]

FreeLibraryAndExitThread looks like able to kill worker threads in openblas dll
Init procedure with spinning up thread per core might be a bit too heavy to do for each BLAS call.

[martin-frbg]

I do not see this on Linux, and cannot test on Windows. Seeing that it appears to happen only when you set up multiple threads it could be a handle leak from mutex locks that are not properly released (not that I would know anything about multithreading on Windows but I found a python issue (10363) that looks vaguely similar; also my earlier attempts to fix apparent threading bugs (PR#1052) were limited to the non-windows parts of the code). Another thing though - just how are you noticing the leak, is this with some tool in VisualStudio, or just watching TaskManager which may not be accurate ?
And which version of OpenBLAS are you using - from another recent issue it seems the nuget one at least is outdated, and even xianyi's 0.2.19 would predate the mentioned thread initialization fixes ?

[martin-frbg]

Come to think of it, could you try the x86 dll I made available in #1073 ? I'm not entirely sure right now but I think I built that one from the development version of that time, which would include the thread locking fixes.

[martin-frbg]

@m3rik, did you get around to doing further tests ?