From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: IGT development <igt-dev@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 3/4] lib: Don't leak children in igt_waitchildren_timeout
Date: Thu, 7 Feb 2019 17:06:55 +0100 [thread overview]
Message-ID: <20190207160655.GV3271@phenom.ffwll.local> (raw)
In-Reply-To: <154955283756.27542.2738484198495367632@skylake-alporthouse-com>
On Thu, Feb 07, 2019 at 03:20:37PM +0000, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-02-07 14:57:06)
> > Instead of cleaning up the mess in igt_exit make sure we don't even
> > let it out of the container. See also
> >
> > commit 754876378d6c9b2775e8c07b4d16f9878c55949f
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date: Fri Feb 26 22:11:10 2016 +0000
> >
> > igt/gem_sync: Enforce a timeout of 20s
> >
> > which added this helper.
> >
> > To make sure that everyone follows the rules, add an assert.
> >
> > We're keeping the cleanup code as a failsafe, and because it speeds
> > up the testcase I'm following up with.
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > lib/igt_core.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > index 49fbf70deb06..a7105f0591fc 100644
> > --- a/lib/igt_core.c
> > +++ b/lib/igt_core.c
> > @@ -1525,6 +1525,7 @@ void igt_exit(void)
> >
> > for (int c = 0; c < num_test_children; c++)
> > kill(test_children[c], SIGKILL);
> > + assert(!num_test_children);
> >
> > if (!test_with_subtests) {
> > struct timespec now;
> > @@ -1842,6 +1843,11 @@ void igt_waitchildren_timeout(int seconds, const char *reason)
> > igt_set_timeout(seconds, reason);
> > igt_waitchildren();
> > igt_reset_timeout();
> > +
> > + for (int c = 0; c < num_test_children; c++)
> > + kill(test_children[c], SIGKILL);
> > +
> > + __igt_waitchildren();
>
> How did we escape?
>
> If the SIGALRM fired, we hit igt_fail() in the parent with children in
> tow, otherwise we completed igt_waitchildren() successfully and cleaned
> everything up.
Hm right, this does nothing.
The motivation for this is that I noticed that without an explicit
igt_waitchildren() the igt_assert forwarding doesn't work. So I've tried
to catch that kind of leaking.
The trouble that does happen is if you run multiple tests, then the
children do leak into the next subtest (since igt_exit is only called at
the very end). That's the usual trouble with our exit handlers not
properly stacking. In the end I wanted to put a wait() into igt_exit and
check that it gives us ECHILD, to make sure everything is cleaned up.
So not sure what to do ... any ideas?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-02-07 16:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 14:57 [igt-dev] [PATCH i-g-t 1/4] lib/tests: Check that igt_assert forwards correctly through igt_fork Daniel Vetter
2019-02-07 14:57 ` [igt-dev] [PATCH i-g-t 2/4] lib/tests: make sure igt_skip in igt_fork is forbidden Daniel Vetter
2019-02-07 14:57 ` [igt-dev] [PATCH i-g-t 3/4] lib: Don't leak children in igt_waitchildren_timeout Daniel Vetter
2019-02-07 15:20 ` Chris Wilson
2019-02-07 16:06 ` Daniel Vetter [this message]
2019-02-07 16:34 ` Daniel Vetter
2019-02-07 14:57 ` [igt-dev] [PATCH i-g-t 4/4] lib/tests: make sure we catch igt_fork leaks Daniel Vetter
2019-02-07 15:07 ` [igt-dev] [PATCH i-g-t] " Daniel Vetter
2019-02-07 15:51 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/4] lib/tests: Check that igt_assert forwards correctly through igt_fork (rev2) Patchwork
2019-02-07 17:06 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190207160655.GV3271@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=igt-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox