CppUnit can't catch it's own exceptions
Reported by Christopher Stawarz | February 12th, 2010 @ 03:32 PM | in 0.5.0 (closed)
The test mw::SchedulerTestFixture::testPeriod10HzNoPayloadChaffX4 sometimes fails. Even though the failure is due to a CPPUNIT_ASSERT, the reported failure message is "uncaught exception of unknown type". This message is generated at line 31 in DefaultProtector.cpp, in a catch(...) clause that follows catch clauses for CppUnit::Exception and std::exception.
Apparently, after CPPUNIT_ASSERT throws an instance of CppUnit::Exception, the runtime stack fails to unwind correctly. This leads to abort() being called, which generates the exception that's caught by the catch(...) clause.
I don't know why the stack fails to unwind. My best guess is that the exception has to pass through some C code that wasn't compiled with -fexceptions. However, adding -fexceptions to CFLAGS when building the mw_supporting stuff doesn't solve the problem.
Comments and changes to this ticket
-
Christopher Stawarz June 23rd, 2010 @ 04:55 PM
- State changed from “new” to “open”
- Assigned user set to “Christopher Stawarz”
This looks relevant: GCC 4.0 C++ Exception Bug
-
Christopher Stawarz January 25th, 2012 @ 03:47 PM
- State changed from “open” to “resolved”
- Milestone order changed from “0” to “0”
Fixed in this commit. The trick was to move the test-running code from MWorksCoreTestRunner to MWorksCoreTest.framework, so that the CppUnit exceptions are both thrown and caught in the same shared library.
-
Christopher Stawarz April 17th, 2012 @ 01:56 PM
- Milestone set to “0.5.0”
- Milestone order changed from “194868” to “0”
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
MWorks accessory libraries, build system, etc.
Christopher Stawarz