Using Spdlog on Windows 32 bits apps always returns error level -1073741819 while closing

[g-tardy]

Since version 1.14.0 of SPDLog I'm having troubles while compiling 32 bits applications that includes SPDLog libs.

When closing the application the app always returns error level -1073741819 on Windows 10 and Windows 11 operating systems whatever the return state of the main.cpp

Version 1.13.0 and below of SPDLog are not affected by this issue.

Compile options: mingw32

Note: The error level really depends on the operating system the application is running:

• Windows 7 64 bits: ErrorLevel defined on main.cpp
• Windows 10 64 bits: -1073741819
• Windows 11: -1073741819

I did not check other operating system as they are not on my scope of use.

It apparently seems to be linked to update of "bundled fmt" to version 10.2.1

[tt4g]

-1073741819 is 0xC0000005, this error code means an access violation.
It appears that something is happening at the end of the application,
However, from the information provided, I cannot determine that it is related to spdlog or fmt.

Could you provide traceback?

[g-tardy]

Thanks @tt4g for getting back to me.

I did a sample app to detail what's the issue (and the fact that it comes from SPDLog version 1.14.0 and above).

The sample is build on a Windows platform using mingw32 (version 8.1.0 - but I do not think the mingw version really matters).
Mingw32 compile path once installed: C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32

Sample attached manages version of spdlog as build variable. Here I used the following conditions:

• -DLoad_SPDLOG=true -DSPDLOG_Version=1.14.1
• -DLoad_SPDLOG=false -DSPDLOG_Version=1.14.1
• -DLoad_SPDLOG=true -DSPDLOG_Version=1.13.0

You will see on code that Load_SPDLOG simply activates or inhibits SPDLog resources.

I build it and run it on a computer with Windows 7 64 bits. In any case it operates right.

Now, when running on Windows 10 computer the %errorLevel% variable varies depending on the compile conditions:

• -DLoad_SPDLOG=true -DSPDLOG_Version=1.14.1 returns -1073741819
• -DLoad_SPDLOG=false -DSPDLOG_Version=1.14.1 returns 0
• -DLoad_SPDLOG=true -DSPDLOG_Version=1.13.0 returns 0

Screenshot detailing this:

Please find attached the sample program (without compiled files nor dll), I will try another comment to send the compile file (if github accept them...)

spdlog-sample.zip

Note: I include as well my CLion Workspace definitions if it can help...

[g-tardy]

Full project path with required dlls and compiled apps

spdlog-sample.zip

[tt4g]

In the source code, spdlog::flush_every() is called, but spdlog::shutdown() is not called.
I think it is because the thread is killed after main().

[g-tardy]

Hi again @tt4g , thanks for getting back to me again.

I tried with the following coding:

    spdlog::get(MAIN_LOGGER)->flush();
    spdlog::drop_all();
    spdlog::shutdown();

    spdlog::drop_all();
    spdlog::shutdown();

    spdlog::get(MAIN_LOGGER)->flush();
    spdlog::shutdown();

    spdlog::shutdown();

In all cases it always return -1073741819...

Note that the code I sent you originally (To adapt) is operating fine when compiled with 64 bits option...

[tt4g]

Please call spdlog::shutdown(); only once at the end of main().

And since the access violation occurs after main(), there may be a problem with resource cleanup by MinGW.

[g-tardy]

Ok, I tried with many different options and possibilities (with console only, file only, with and without flush methods...).

Here is code it turned finally turned out:

const char * const MAIN_LOGGER = "MAIN";

int main (int argc, char *argv[])
{
    spdlog::cfg::load_argv_levels(argc, argv);
    auto console_sink = make_shared<spdlog::sinks::stdout_color_sink_mt>();
    console_sink->set_level(spdlog::level::info);
    auto file_sink = make_shared<spdlog::sinks::rotating_file_sink_mt>("log", 1024 * 1024 * 5, 20);
    file_sink->set_level(spdlog::level::debug);
    spdlog::sinks_init_list sinks { console_sink};
    spdlog::register_logger(make_shared<spdlog::logger>(MAIN_LOGGER, sinks));
    spdlog::get(MAIN_LOGGER)->set_level(spdlog::level::trace);
    // spdlog::get(MAIN_LOGGER)->info("We are starting"); // Uncomment this will return error `-1073741819`
    spdlog::shutdown();
    return EXIT_SUCCESS;
}

So as long as I ask to log something, it returns with error

I cannot go further on testings.

I will try to pull commits between versions 1.13.0 and 1.14.1 to point out when SDPLog started to return this error

[g-tardy]

Ok, it took me a while, but I was finally able to catch the commit culprit:
1253a57

With this commit I'm starting to get troubles as mentioned previously.

I'm not really involved in the process, but if you wish me to make some more tests, or check compile result, please feel free to get back to me!

[tt4g]

It appears that MinGW has a problem with the combined use of the thread_local and std::* objects.

• MinGW-w64 - for 32 and 64 bit Windows / Bugs / #527 thread_local stl object's destructor causing crash

The report is from 2017, but if this bug is still there, it is a compiler issue and spdlog cannot fix it.

[tt4g]

In the latest source code (not yet released), You can avoid using thread_local std::map<std::string, std::string> in spdlog if defines the SPDLOG_NO_TLS macro: #3184
If you try this and the problem no longer occurs, you can isolate it as a MinGW bug: msys2/MINGW-packages#2519

[tt4g]

I found a report of the same problem: #3100

[g-tardy]

Well catch @tt4g !

I checked on branch 1.x and it worked perfectly by adding compile option -DSPDLOG_NO_TLS=true to cmake command line

So yes, I agree that it's an issue from mingw. the thing that I do not really catch, is that's it only affected 32 bits compilation.

Anyhow, as you correctly mentioned, this is an issue from mingw, and the solution provided works perfectly.

Thanks again for all the support