boost::log access violation with global objects destructors
Hello, Boost.Log creates an access violation when global objects being destructed attemps to log something. The doc says that I have to keep a shared_ptr to the core, but even doing so doesn't seem to work. I created a simple testcase here: http://codepad.org/pr8fAiZ2 The access violation location changes when the code change so I'm not sure how to handle this. This happens on Windows XP with boost 1.43 and the latest boost.log source from the svn. Thanks in advance! Philippe
On 05/28/2010 09:35 PM, Philippe Vaucher wrote:
Hello,
Boost.Log creates an access violation when global objects being destructed attemps to log something. The doc says that I have to keep a shared_ptr to the core, but even doing so doesn't seem to work.
I created a simple testcase here: http://codepad.org/pr8fAiZ2
It doesn't crash on my Ubuntu. I'll try Windows tomorrow. Considering the code snippet, the core is sure to be intact. But it's just one of the requirements to be able to write logs in global destructors. There are other things required, such as the logger. I would recommend to store the logger in the global object to guarantee that. However, as far as I can see your particular code snippet should be fine in this regard. Strange.
Considering the code snippet, the core is sure to be intact. But it's just one of the requirements to be able to write logs in global destructors. There are other things required, such as the logger. I would recommend to store the logger in the global object to guarantee that. However, as far as I can see your particular code snippet should be fine in this regard. Strange.
Here is a little more information: this happens with VC++ express 2008. It originally happend with a severity_logger_mt when Qt issued a qWarning() after main() returned from within a destructor and I wanted to log that warning. The access violation was within some mutex/lock code from boost::thread, but I also saw it fail in boost::intrusive or other libs boost::log was using depending on how I moved code around. I'll try to provide a trace on monday. Philippe
On 29.05.2010 3:04, Philippe Vaucher wrote:
Considering the code snippet, the core is sure to be intact. But it's just one of the requirements to be able to write logs in global destructors. There are other things required, such as the logger. I would recommend to store the logger in the global object to guarantee that. However, as far as I can see your particular code snippet should be fine in this regard. Strange.
Here is a little more information: this happens with VC++ express 2008. It originally happend with a severity_logger_mt when Qt issued a qWarning() after main() returned from within a destructor and I wanted to log that warning. The access violation was within some mutex/lock code from boost::thread, but I also saw it fail in boost::intrusive or other libs boost::log was using depending on how I moved code around. I'll try to provide a trace on monday.
Hmm, it seems that this problem is, too, related to the compiler-supplied TLS. The thread-specific attributes cannot be acquired by the core when the global destructors are run. Try defining BOOST_LOG_NO_COMPILER_TLS and rebuilding Boost.Log, it solved the problem for me. PS: I guess, the compiler-supplied TLS is a too hazardous optimization. I'll make it disabled by default in the next release.
On Sat, May 29, 2010 at 1:06 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
PS: I guess, the compiler-supplied TLS is a too hazardous optimization. I'll make it disabled by default in the next release.
+1. Best Regards, Christoph
Hmm, it seems that this problem is, too, related to the compiler-supplied TLS. The thread-specific attributes cannot be acquired by the core when the global destructors are run. Try defining BOOST_LOG_NO_COMPILER_TLS and rebuilding Boost.Log, it solved the problem for me.
I confirm the problem is gone with BOOST_LOG_NO_COMPILER_TLS defined. Thanks! Philippe
participants (3)
-
Andrey Semashev -
Christoph Heindl -
Philippe Vaucher