Re: Getting SIGKILL to work in MariaDB

On Mon, 2019-08-12 at 13:49 +0100, Tom Hughes wrote:
> On 12/08/2019 13:15, Michael Widenius wrote:
> 
> > The request I would like you to consider is to do one of the following:
> > - Ensure that sending a sigkill works and in this case there should
> > not be any valgrind leak report.
What version of Valgrind are you using ?

I recently fixed (10 of July) in the git repository a bug with an infinite loop
or a hang when a process sends a signal to itself.

See bugs 409141 and 409367.

So, you might test with a recent git version of Valgrind.

> > - Add an api call where we could specify that we don't want any leak
> > reports from now on.  If this would exist then I could call this when
> > we are about to send the SIGFPE/SIGKILL signal to the server.
A stackoverflow discussion led to a suggestion to have a
monitor command/client request to load a new suppression file.
This would allow to load a supp file suppressing all leaks.

Allowing to load a suppression file via a client request might be useful
in other circumstances (the stackoverflow case was to avoid any leak
search when a program fails between a fork and an exec, but it
could be used to suppress flexibly whatever kind of errors and/or
automatically load a supp file e.g. when loading a shared lib).

Alternatively, the only reason why valgrind can do a leak search
when your process calls "kill (me, 9);"
is that valgrind is intercepting the syscall and does a leak
search before really self-killing.

You can avoid this interception by instead doing something like
   system("kill -9 me");
as no way valgrind will be able to intercept this.
(of course, me has to be the pid of the calling process).

Philippe



> 
> Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
> and attach a minimal test case if at all possible.
> 
> Also the output of running valgrind with --trace-signals=yes would be
> a good thing to provide.
> 
> Tom
>