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.