Branden Archer - 2014-06-22

Thanks for reporting this bug.

Indeed, you are right. Running a checked teardown that calls a failing
assert in CK_NOFORK mode causes an infinite loop.

At one point, I ran into the same thing. When getting Check to compile on
platforms without fork() [e.g. Windows] Check needed to compile without
fork() support. As a part of that, functionality that did not make sense
was stubbed out and tests which would blatantly fail were omitted. The
checked setup/teardown functionality was also stubbed out, as it would not
provide the functionality it advertised. Namely, the checked setup/teardown
calls would run in the address space of the test, and it was assume that
was different for each test due to using fork(). So, on Windows (or when
--disable-fork is used) checked setup/teardown calls are disabled.

The interesting part to this is that it did not occur to me that when
fork() was available one could run tests in CK_NOFORK mode and still used
checked setup/teardown functions. That should have been obvious, but it did
not occur to me.

The fix to get checked teardown functions to behave nicely when an
assertion fails should not be difficult. However, it brings up some
questions.

If using checked setup/teardown functions is valid in CK_NOFORK mode (and,
with more documentation on the expectation of such calls, it can be), there
may still be a few differences between what happens when a checked
setup/teardown function fails in both CK_FORK and CK_NOFORK mode. As things
stand currently, a failed checked teardown in CK_FORK mode will fail the
test. However, in CK_NOFORK mode the test will not be marked as failed. I
will look into this and see if the behavior for CK_NOFORK can be made to
that of CK_FORK.

Anyway, thanks for the bug report. I've some changes locally that should
address the bug you have reported. When I am more confident that they do
not cause other issues, I will push them and close the bug.

  • Branden