On Tue, Oct 08, 2019 at 11:22:48PM -0700, Enji Cooper (yaneurabeya) wrote: > > > 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) Disagree to what ? How this citation is relevant to my statement that there are tests that use fork and ATF_ in children, I know about ptrace(2) tests at least.
> > 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. This is not a way at all. Fork/wait is needed to create the child in controlled matter, sometimes we must even know precisely which syscalls are executed both by parent and child on their path. We need exactly the bare-bone syscalls to create the testing situation. > > 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. Can we have some testing framework where tests can be conveniently debugged, for the start ? _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
