Boost::Test: intermittent crash during testing

[anonymous]

Our tests spin up 64 threads and then exercise various objects. Upon thread exit, the thread prints a simple message (args.id is the internal thread number):

BOOST_MESSAGE( "Thread " << args.id << " completed" );

The problem is tough to reproduce, but I've got one under the debugger. It appears Boost::Test has missed a lock in execution_monitor.

We are compiling with both CXXFLAGS += -D_REENTRANT and LDLIBS += -lpthread. Boost::Test compilation page (http://www.boost.org/doc/libs/1_47_0/libs/test/doc/html/execution-monitor/compilation.html) does not specify any additional flags for multithreaded testing, and the FAQ (http://www.boost.org/doc/libs/1_47_0/libs/test/doc/html/faq.html) does not mention any special steps.

Console 1

$ ./test/run_esapi_tests Running 30 test cases... terminate called after throwing an instance of 'std::length_error'

what(): basic_string::_S_create

[Program hangs here]

Console 2

$ ps -a

PID TTY TIME CMD

14779 pts/0 00:00:01 run_esapi_tests 14846 pts/1 00:00:00 ps $ gdb attach 14779 GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. ... Loaded symbols for /lib/libpthread.so.0 ... Loaded symbols for /lib/librt.so.1 lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 136 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.

in ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S

(gdb) where #0 lll_lock_wait ()

at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136

#1 0x00007f24bdc595f4 in _L_lock_1024 () from /lib/libpthread.so.0 #2 0x00007f24bdc59457 in pthread_mutex_lock (mutex=0x7f24be08d948)

at pthread_mutex_lock.c:82

#3 0x00007f24bcb1155b in *GI_dl_iterate_phdr (

callback=0x7f24bcd81910 <_Unwind_IteratePhdrCallback>, data=0x80) at dl-iteratephdr.c:42

#4 0x00007f24bcd8263f in _Unwind_Find_FDE (pc=0x7f24bcd80b1d,

bases=0x7fffa8e28498) at ../../../src/libgcc/../gcc/unwind-dw2-fde-glibc.c:417

#5 0x00007f24bcd7fb93 in uw_frame_state_for (context=0x7fffa8e283f0,

fs=<value optimized out>) at ../../../src/libgcc/../gcc/unwind-dw2.c:1128

#6 0x00007f24bcd804a9 in uw_init_context_1 (context=0x7fffa8e283f0,

outer_cfa=0x7fffa8e28530, outer_ra=0x7f24bcf861c0) at ../../../src/libgcc/../gcc/unwind-dw2.c:1447

#7 0x00007f24bcd80b1e in _Unwind_RaiseException (exc=0x125a8a0)

at ../../../src/libgcc/../gcc/unwind.inc:88

#8 0x00007f24bd2d4e31 in cxa_throw (obj=<value optimized out>, tinfo=0x80,

dest=0) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:78

#9 0x00007f24bd9e755a in boost::execution_monitor::catch_signals (

this=<value optimized out>, F=<value optimized out>) at ./boost/test/impl/execution_monitor.ipp:958

#10 0x00007f24bd9e759b in boost::execution_monitor::execute (

this=0x7f24bdc4f8c0, F=...) at ./boost/test/impl/execution_monitor.ipp:1282

#11 0x00007f24bda01d8c in boost::unit_test::unit_test_monitor_t::execute_and_translate (this=0x7f24bdc4f8c0, tc=<value optimized out>)

at ./boost/test/impl/unit_test_monitor.ipp:69

#12 0x00007f24bd9f2941 in boost::unit_test::framework_impl::visit (

this=0x7f24bdc4f800, tc=<value optimized out>) at ./boost/test/impl/framework.ipp:150

#13 0x00007f24bda21763 in boost::unit_test::traverse_test_tree (suite=...,

V=...) at ./boost/test/impl/unit_test_suite.ipp:207

#14 0x00007f24bd9efc28 in boost::unit_test::framework::run (

id=<value optimized out>, continue_test=16) at ./boost/test/impl/framework.ipp:436

#15 0x00007f24bd9fed43 in boost::unit_test::unit_test_main (

init_func=<value optimized out>, argc=<value optimized out>, argv=<value optimized out>) at ./boost/test/impl/unit_test_main.ipp:185

#16 0x000000000042e402 in main (argc=1, argv=0x7fffa8e295e8)

at /usr/include/boost/test/unit_test.hpp:59

(gdb)

[noloader@…]

Whoops.... better join this bug report.

[Jeffrey Walton <noloader@…>]

My bad - this should be against 1.40, not 1.47.

[Gennadiy Rozental]

what lock you refer to?

Boost.Test never promised to be thread safe. All synchronization for now is user responsibility.

[Gennadiy Rozental]

Let's reconsider this once Boost.Test start using C++11 synchronization primitives