Somehow it seems that our port is not thread safe when it comes to initializing static C++ objects. I.e. if two threads happen to initiate a static object initialization (e.g. by using local static objects) at the same time, a recursion is very likely which ends up with this exception:
PASS : tst_QAbstractAnimation::avoidJumpAtStart()
terminate called after throwing an instance of '__gnu_cxx::recursive_init_error'
what(): std::exception
Killed by SIGABRT
pid=0xb7cc ppid=0xb7cb tid=0x0003 slot=0x007f pri=0x0200 mc=0x0001 ps=0x0010
D:\CODING\QT5\QT5-DEV-BUILD\QTBASE\TESTS\AUTO\CORELIB\ANIMATION\QABSTRACTANIMATION\DEBUG\TST_QABSTRACTANIMATION.EXE
I found it out when debugging Qt tests, see bitwiseworks/qtbase-os2#29 (comment) for the full story. I guess we need a standalone test case but the problem described there is a good test case per se. At least, it can be used to model a standalone one.
Given that Qt has a workaround for this, I'm not going to invest any time in it right now. But it may affect other applications as well so it should be dealt with sooner or later.
Somehow it seems that our port is not thread safe when it comes to initializing static C++ objects. I.e. if two threads happen to initiate a static object initialization (e.g. by using local static objects) at the same time, a recursion is very likely which ends up with this exception:
I found it out when debugging Qt tests, see bitwiseworks/qtbase-os2#29 (comment) for the full story. I guess we need a standalone test case but the problem described there is a good test case per se. At least, it can be used to model a standalone one.
Given that Qt has a workaround for this, I'm not going to invest any time in it right now. But it may affect other applications as well so it should be dealt with sooner or later.