debug mode log4cxx.dll crash

[qq952670771]

os : win11 x64 version:26100.1742
build tools : vs2022
mode : debug.
ouput type : dll
log4cxx version: 1.5.0

Automatically compile log4cxx.dll using vcpkg ,

The application crashed during initialization when it was running(debug mode).
In the release mode, it is normal.

This is the call stack information.

 	ucrtbased.dll!00007fffd83a0f54()	unkown
 	ucrtbased.dll!00007fffd839f495()	unkown
 	log4cxx.dll!operator delete(void * block) 行 38	C++
 	log4cxx.dll!operator delete(void * block, unsigned __int64 __formal) 行 32	C++
 	log4cxx.dll!std::_Deallocate<16,0>(void * _Ptr, unsigned __int64 _Bytes) 行 255	C++
 	log4cxx.dll!std::_Default_allocator_traits<std::allocator<std::_Container_proxy>>::deallocate(std::allocator<std::_Container_proxy> & _Al, std::_Container_proxy * const _Ptr, const unsigned __int64 _Count) 行 670	C++
 	log4cxx.dll!std::_Deallocate_plain<std::allocator<std::_Container_proxy>>(std::allocator<std::_Container_proxy> & _Al, std::_Container_proxy * const _Ptr) 行 984	C++
 	log4cxx.dll!std::_Delete_plain_internal<std::allocator<std::_Container_proxy>>(std::allocator<std::_Container_proxy> & _Al, std::_Container_proxy * const _Ptr) 行 997	C++
 	log4cxx.dll!std::string::~basic_string<char,std::char_traits<char>,std::allocator<char>>() 行 3275	C++
>	log4cxx.dll!log4cxx::helpers::Class::registerClass(const log4cxx::helpers::Class & newClass) 行 176	C++
 	log4cxx.dll!log4cxx::helpers::ClassRegistration::ClassRegistration(const log4cxx::helpers::Class &(*)() accessor) 行 27	C++
 	baseapp.exe!log4cxx::helpers::WideLife<log4cxx::helpers::ClassRegistration>::WideLife<log4cxx::helpers::ClassRegistration><log4cxx::helpers::Class const & (__cdecl&)(void)>(const log4cxx::helpers::Class &(*)() arg0) 行 50	C++
 	baseapp.exe!log4cxx::ScriptLevel::registerClass() 行 10	C++
 	baseapp.exe!log4cxx::classes::`dynamic initializer for 'ScriptLevelRegistration''() 行 10	C++
 	baseapp.exe!_initterm(void(*)() * first, void(*)() * last) 行 22	C++
 	[External code]	

173 bool Class::registerClass(const Class& newClass)
174  {
175     getRegistry()[StringHelper::toLowerCase(newClass.getName())] = &newClass;
176     return true;
177  }

[rm5248]

can you provide a minimum complete example that will cause this crash?

[swebb2066]

I believe this is most likely an example of Static Initialization Order Fiasco.

To avoid this, you can put your extension class(es) (and the IMPLEMENT_LOG4CXX_OBJECT macro) in a dynamic library (DSO/DLL) that is loaded before loading the Log4cxx configuration file. Alternatively, you could call ScriptLevel::registerClass() before loading the configuration file.

[qq952670771]

can you provide a minimum complete example that will cause this crash?

It is the initialization in this global macro.
IMPLEMENT_LOG4CXX_LEVEL(ScriptLevel)

Based on my breakpoint debugging, the problem occurred when destructing the temporary variable StringHelper::toLowerCase(newClass.getName()). The program crashed at that point.

[qq952670771]

I believe this is most likely an example of Static Initialization Order Fiasco.

To avoid this, you can put your extension class(es) (and the IMPLEMENT_LOG4CXX_OBJECT macro) in a dynamic library (DSO/DLL) that is loaded before loading the Log4cxx configuration file. Alternatively, you could call ScriptLevel::registerClass() before loading the configuration file.

IMPLEMENT_LOG4CXX_LEVEL(ScriptLevel)
This is a global macro that is initialized before the main function is called.

[qq952670771]

I believe this is most likely an example of Static Initialization Order Fiasco.

To avoid this, you can put your extension class(es) (and the IMPLEMENT_LOG4CXX_OBJECT macro) in a dynamic library (DSO/DLL) that is loaded before loading the Log4cxx configuration file. Alternatively, you could call ScriptLevel::registerClass() before loading the configuration file.

I understand what you mean. Then how should it be revised? Change each of the obtained places into static functions, and then return the result through these functions?

[swebb2066]

There isn't any simple code change available that always avoids SIOF. Using a separate dll for Log4cxx extension code is the only general approach. It is similar to the fix that C++ modules offers.

However, I am now not certain your problem is SIOF. An exception when calling delete usually means the heap is corrupt (eg. heap buffer overflow, use after free etc).

That would mean the problem is elsewhere in your code and the symptom you are seeing in log4cxx::helpers::ClassRegistration::ClassRegistration is because it is a heap operation after the heap was corrupted.

To isolate heap corruption you need to use address sanitizer options on the compiler, or cut modules from your application until the problem dissappears.

[qq952670771]

There isn't any simple code change available that always avoids SIOF. Using a separate dll for Log4cxx extension code is the only general approach. It is similar to the fix that C++ modules offers.

However, I am now not certain your problem is SIOF. An exception when calling delete usually means the heap is corrupt (eg. heap buffer overflow, use after free etc).

That would mean the problem is elsewhere in your code and the symptom you are seeing in log4cxx::helpers::ClassRegistration::ClassRegistration is because it is a heap operation after the heap was corrupted.

To isolate heap corruption you need to use address sanitizer options on the compiler, or cut modules from your application until the problem dissappears.

It should be the problem you mentioned - SIOF. I moved the corresponding initialization code to the simplest project and also loaded the corresponding log4cxx.dll. There were no issues.