Martin Wille wrote:
Recently a problem came up with program_options/cmdline_test_dll. Several times, my computer crashed and I haven't been able to figure out the reason for it. Today, I was lucky to see that test eating up all the memory and CPU. So it looks like it ran into an infinite loop. This for several times has been an indicator for something going wrong with the signal handling in Boost.Test; this time, it also looks like Boost.Test is the culprit; strace shows output similar to the other cases:
--- SIGABRT (Aborted) @ 0 (0) --- rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 kill(21453, SIGABRT) = 0
Hmm.... the test worked OK for me! I'm really interested to figure out where the SIGABRT comes from: maybe some assert fires.
This type of failure is a showstopper for testing. I suggest to disable the sigaction based signal handling in Boost.Test at least for gcc 2 and for como. Perhaps, other compilers are also affected.
You mean the problems is only on those two toolsets? Yes, I think disabling signal handling in Boost.Test to see where the test fails would be very desired. BTW, you mention como, but I don't see that toolset in linux regression results. - Volodya