> On Oct 8, 2019, at 08:04, Konstantin Belousov <kostik...@gmail.com> wrote:
>
> On Tue, Oct 08, 2019 at 01:43:05PM +0000, Eric van Gyzen wrote:
>> Author: vangyzen
>> Date: Tue Oct 8 13:43:05 2019
>> New Revision: 353305
>> URL: https://svnweb.freebsd.org/changeset/base/353305
>>
>> Log:
>> Fix problems in the kern_maxfiles__increase test
>>
>> ATF functions such as ATF_REQUIRE do not work correctly in child processes.
>> Use plain C functions to report errors instead.
> There are much more tests that fork and use ATF_ in children.
> Look e.g. at most ptrace(2) tests.
I beg to disagree:
86 /*
87 * A variant of ATF_REQUIRE that is suitable for use in child
88 * processes. This only works if the parent process is tripped up by
89 * the early exit and fails some requirement itself.
90 */
91 #define CHILD_REQUIRE(exp) do { \
92 if (!(exp)) \
93 child_fail_require(__FILE__, __LINE__, \
94 #exp " not met"); \
95 } while (0)
The issue, in this particular case, and the item that evangyzen was fixing, was
the fact that failures in children can result in very confusing failures from a
parent level. In particular, ATF_CHECK does not trickle up to parents and
ATF_REQUIRE* gets thrown up to parents as abort()’ed processes.
The best way to handle this within the atf-c/atf-c++ framework (with less
boilerplate) is to use these APIs: atf_utils_fork(..)/atf_utils_wait(..). You
will still need to use `_exit` (instead of
exit(..)/assert(..)/ATF_CHECK(..)/ATF_REQUIRE(..), but it’s a lot less
boilerplate than writing it yourself.
Again, this is why I was driving towards GoogleTest. Despite the fact that it’s
a C++ framework, there’s a lot less confusing boilerplate involved and context,
since things are executed in relatively the same context, i.e., setup -> test
-> teardown, and they’re easier to follow.
The best way to move forward usability-wise with this (I think) is to probably
alias the ATF_* macros to something more sensible when forking processes.
However, given the amount of complaints I’ve heard about ATF, I think it’s best
not to build upon an unstable foundation, but instead encourage the use of
something more widely-accepted across the open source community/straightforward
use wise. In this case, googletest.
Thanks,
-Enji
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
