From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-05 02:20:35
Martin Wille wrote:
> >>--- 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.
> The short version:
> Usually *some* signal is raised and caught, siglongjumping()
> to some other location on the call stack confuses exception
> handling. An exception is thrown, the (confused) exception
> handling mechanism thinks it is invalid and calls terminate()
> which in turn calls abort(). abort() raises the SIGABRT,
Ah.. so the original signal was not necessary SIGABRT. Anyway, it's
interesting to know what it was, or why the test decided to fail in the first
> The problem is known to exist on como. That's actually the major
> reason for como not being on the list of regression results.
> The code exploits UB, and I'm expecting it to cause problems
> with other toolsets, too, some day. However, other than to
> disable the sigaction/siglongjmp based signal handling, I have
> no suggestion to fix it.
I've only now realized that the code tries to throw from signal handler...
well, that's really UB!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk