#310 win32: crash under ApplicationVerifier during resource cleanup

[Dennis Yolkin]

I have a DLL statically linked with log4cplus. If I load it at runtime and immediately unload it crashes.

Code:

HMODULE loaded = LoadLibrary(L"mylib.dll ");
FreeLibrary(loaded);

When FreeLibrary is called, thread_callback() is called with fwdReason==DLL_PROCESS_DETACH. Finally it calls TlsGetValue(), but it crashes with message "Invalid TLS index used for current stack trace." It is because initializeLog4cplusApcProc() that was scheduled in thread_callback (DLL_PROCESS_ATTACH) haven't been called yet, so TlsAlloc was not called

[Václav Haisman]

Are you using C run time library in your DLL as a static library (libCMT) or as a DLL (MSVCRT)?

[Dennis Yolkin]

MSVCRT

[Václav Haisman]

Hmm, that is unexpected. I guess you could call initializeLog4cplus() between the LoadLibrary and the FreeLibrary lines yourself.

[Dennis Yolkin]

yes, it is workaround that I use now

[Dennis Yolkin]

BTW, if I do SleepEx(0, TRUE); between LoadLibrary() and FreeLibrary() all goes well - thread becomes to alertable state and initializeLog4cplusApcProc() is called

[Václav Haisman]

That explains something.

Unfortunately, I cannot think of a way of initializing log4cplus that would work all the time in all circumstances and build variations. I guess the APC callback trick works only if your DLL was not dynamically loaded with LoadLibrary() but linked in statically. I think that the best I can do is to document this and suggest the call to initializeLog4cplus() immediately after the LoadLibrary() if log4cplus is built statically and the client DLL is not linked in statically.

[Dennis Yolkin]

Maybe the solution is just to check if log4plus was initialized in thread_callback in case DLL_PROCESS_DETACH?