Deadlock with ELPP_AS_DLL and ELPP_THREAD_SAFE defined on Windows 7 (and lower)

[grishavanika]

How to reproduce (v 9.80):

• Create DLL with next files:

// log.h
#ifndef LOG_H_
#define LOG_H_
#define ELPP_AS_DLL
#if defined(EL_EXPORTS)
#  define ELPP_EXPORT_SYMBOLS
#endif
#define ELPP_THREAD_SAFE
#include "easyloggingpp/easylogging++.h"
#endif

// log.cpp
#include "log.h"
INITIALIZE_EASYLOGGINGPP

• Create an application and link it to this dll

// main.cpp
#include <iostream>
#include "../el/log.h"
int main()
{
    std::cout << "TEST\n";
    LOG(ERROR) << "TEST";
}

(solution for Microsoft Visual Studio 2013) Compile an run it on Windows 7. Application will stuck and you will not see any console output.

• To compile it you need to fix linker error firstly. I add comment on #150

Looks like the problem is with using std::mutex (possibly call to ::CreateMutex()) as global variable. Here are few links, that has such problem with using std::mutex inside ::DllMain():

• C++11 std::mutex in Visual Studio 2012 deadlock when locked from DllMain()
• Deadlock when locking std::mutex during DllMain static initialization

The simplest solution is to use CRITICAL_SECTION instead std::mutex. So, in case of Windows, I fix the problem by using class Mutex:

#if ELPP_OS_WINDOWS && defined(ELPP_AS_DLL) && ELPP_THREADING_ENABLED
#  if defined(ELPP_USE_STD_THREADING)
#    undef ELPP_USE_STD_THREADING
#  endif
#endif

I do not see such problem on Windows 8 (8.1). And found it on Windows 7 that is running on VM,

Thanks

[abumq]

We can safely undefine ELPP_USE_STD_THREADING to use CRITICAL_SECTION as you suggested. Leaving this open for other suggestions using std::mutex (or to later have a look at links in detail)