Re: [Qemu-devel] [PATCH v2 2/7] iotests: exclude killed processes from running under Valgrind

From: Kevin Wolf <kwolf@redhat.com>
To: Roman Kagan <rkagan@virtuozzo.com>,
	Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com,
	berrange@redhat.com, den@openvz.org, vsementsov@virtuozzo.com
Subject: Re: [Qemu-devel] [PATCH v2 2/7] iotests: exclude killed processes from running under Valgrind
Date: Mon, 17 Jun 2019 14:53:55 +0200	[thread overview]
Message-ID: <20190617125355.GH7397@linux.fritz.box> (raw)
In-Reply-To: <20190617121855.GB32624@rkaganb.sw.ru>

Am 17.06.2019 um 14:18 hat Roman Kagan geschrieben:
> On Mon, Jun 17, 2019 at 01:15:04PM +0200, Kevin Wolf wrote:
> > Am 11.06.2019 um 20:02 hat Andrey Shinkevich geschrieben:
> > > The Valgrind tool fails to manage its termination when QEMU raises the
> > > signal SIGKILL. Lets exclude such test cases from running under the
> > > Valgrind because there is no sense to check memory issues that way.
> > > 
> > > Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
> > 
> > I don't fully understand the reasoning here. Most interesting memory
> > access errors happen before a process terminates. (I'm not talking about
> > leaks here, but use-after-free, buffer overflows, uninitialised memory
> > etc.)
> 
> Nothing of the above, and nothing in general, happens in the usermode
> process upon SIGKILL delivery.

My point is, the interesting part is what the program does before
SIGKILL happens. There is value in reporting memory errors as long as we
can, even if the final check doesn't happen because of SIGKILL.

> > However, I do see that running these test cases with -valgrind ends in a
> > hang because the valgrind process keeps hanging around as a zombie
> > process and the test case doesn't reap it. I'm not exactly sure why that
> > is, but it looks more like a problem with the parent process (i.e. the
> > bash script).
> 
> It rather looks like valgrind getting confused about what to do with
> raise(SIGKILL) in the multithreaded case.

Well, valgrind can't do anything with SIGKILL, obviously, because it's
killed immediately. But maybe the kernel does get confused for some
reason. I get the main threads as a zombie, but a second is still
running. Sending SIGKILL to the second thread, too, makes the test case
complete successfully.

So I guess the main question is why the second thread isn't
automatically killed when the main thread receives SIGKILL.

Kevin