memory errors and eventual segfault when using Log

[Giovanni Azua <bravegag@…>]

Hello,

I'm using the the Log component of Boost 1.54 compiled from source and I get many memory errors and segfault while invoking the function logging::add_file_log. To make sure it was not my code, I went to the Boost installation and ran valgrind on some of the Log examples that invoke that function and it happens also there. The minimalistic example tutorial_file.cpp reveals the issue (though there may be more issues with Log). I get many memory errors in Mac OS X and Ubuntu, in Mac OS X it doesn't crash the application but I get a segfault in Ubuntu.

I'm attaching the valgrind output on Ubuntu 12.04 with kernel version "Linux HPC 3.5.0-40-generic #62~precise1-Ubuntu SMP Fri Aug 23 17:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux".

Best regards, Giovanni

[Giovanni Azua <bravegag@…>]

valgrind output

[Giovanni Azua <bravegag@…>]

The attached file was generated with the command:

valgrind --show-reachable=yes --dsymutil=yes --track-origins=yes ./tutorial_file 2> valgrind.log

[Andrey Semashev]

I believe, this is caused by #8642.

To workaround try removing all sinks prior to returning from main().

[Giovanni Azua <bravegag@…>]

Thank you for your suggestion, however this happens during logging initialization and not prior to returning from main.

[Andrey Semashev]

The valgrind log you attached points to an invalid memory access during the global destructors execution. Do you have a log that shows a different crash?

[Giovanni Azua <bravegag@…>]

OK attached valgrind2.log that shows my application startup crashing due to this same issue. The same code does not segfault in Mac OS X but the errors are revealed in valgrind also in Mac OS X.

[Giovanni Azua <bravegag@…>]

Please note that the last crash is triggered while invoking logging::add_file_log

[Andrey Semashev]

It looks like now the crash happens during global constructors stage, but still in the code related to the global locale initialization in Boost.Filesystem. I haven't seen this one before, but I don't see how it can be fixed on Boost.Log side.

[Andrey Semashev]

It seems the problem is isolated in Boost.Filesystem (more precisely, its global locale initialization). I'm reassigning the ticket to Boost.Filesystem maintainer, I hope he can suggest a solution.