posix_time::operator<< crashes with double free under possible race conditions

[szubkov@…]

We are using boost 1.39.0 compiled with gcc 3.4.6, and we're getting a glibc "double free or corruption" crash on this line in one of our multithreaded programs:

mLogFile << boost::posix_time::microsec_clock::local_time() (where mLogFile is of type ofstream)

The crash behaves like a race condition, small changes to unrelated code make it disappear.

The crash does does not happen if we use operator<< on to_simple_string(microsec_clock::local_time()), which is what we'll be using for now. But it would be nice if someone could take a look, maybe it's easy:

gdb backtrace:

#0 0xffffe410 in kernel_vsyscall ()

#1 0x4029b541 in raise () from /lib/tls/libc.so.6

#2 0x4029cdbb in abort () from /lib/tls/libc.so.6

#3 0x402d18b5 in libc_message () from /lib/tls/libc.so.6

#4 0x402d7842 in malloc_printerr () from /lib/tls/libc.so.6

#5 0x402d81f4 in free () from /lib/tls/libc.so.6

#6 0x40215c61 in operator delete () from /usr/lib/libstdc++.so.6

#7 0x401f28cd in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6

#8 0x401f3a78 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() from /usr/lib/libstdc++.so.6

#9 0x0807777c in boost::as_literal<std::string> (r=@0x40bb3190) at as_literal.hpp:109

#10 0x08076c68 in boost::algorithm::first_finder<std::string> (Search=@0x40bb3190) at finder.hpp:55

#11 0x08075a85 in boost::algorithm::erase_all<std::string, std::string> (Input=@0x40bb31b0, Search=@0x40bb3190) at erase.hpp:593

#12 0x08072167 in boost::date_time::time_facet<boost::posix_time::ptime, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::put (this=0x8102d28, a_next={<std::iterator<std::output_iterator_tag,void,void,void,void>> = {<No data fields>}, _M_sbuf = 0x80def98, _M_failed = false}, a_ios=@0x80df020, a_fill=32 ' ', a_time=@0x40bb32c8) at time_facet.hpp:325

#13 0x08070aca in boost::posix_time::operator<< <char, std::char_traits<char> > (os=@0x80def94,p=@0x40bb32c8) at posix_time_io.hpp:53

#14 0x0806f392 in LoggerThread::WriteMessageToDisk (this=0x80deed0, event_to_log={px = 0x8100328, pn = {pi_ = 0x8100080}}) at LoggerThread.cc:116

[Andrey Semashev]

Is the streaming expression protected with a mutex lock or a similar synchronization mechanism? If not, that is the most probable source of the problem.

If that doesn't help, a short code snippet that demonstrates the problem would be nice.

[szubkov@…]

We haven't seen this issue reappear, so perhaps it was a temporary lapse in synchronization after all. Can be closed.