Re: [Valgrind-users] 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
>
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Getting SIGKILL to work in MariaDB
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. - 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. 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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Getting SIGKILL to work in MariaDB
Hi! I am the creator of MySQL and MariaDB and a valgrind user since a LONG time! valgrind has been used to verify the integrity of MySQL since the very early times of valgrind! I have a small request to solve a small problem with valgrind in MariaDB: To be able to test recovery during testing, our test system takes down the mysqld server process hard and schedules a restart of the server. We used to do that by sending sigkill internally in the the server to itself and then the test waits for the server to restart and then the test continues. I noticed recently that when running the server under valgrind, the sigkill was ignored and thus the test stalled. (I think this worked with some earlier version of valgrind, but I am not sure about this) I have now fixed this by sending a SIGFPE signal instead and setting an internal variable to mark that we shouldn't write to the log that the server died (as the test system who examines the logs would think something went wrong). The problem is that when the server dies hard with SIGFPE, the memtool writes out the leaks and the test system thinks something is wrong. 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. - 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. Something like the following would be very useful: VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...) Regards, Monty ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Valgrind with CUDA: noted but unhandled ioctl with no size/direction hints
Hi everyone.
I'm trying Valgrind on a simple CUDA program for CPU memory check (It
worked for GPU memcheck when using cuda-memcheck):
```
#include
int main()
{
void *dp = NULL;
cudaMalloc(, 1024);
cudaFree(dp);
void *p = NULL;
p = malloc(1024);
free(p);
cudaDeviceReset();
return 0;
}
```
The program hangs with many `noted but unhandled ioctl with no
size/direction hints` warnings.
```
$ nvcc prog.cu
$ valgrind ./a.out
==61517== Memcheck, a memory error detector
==61517== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==61517== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==61517== Command: ./a.out
==61517==
==61517== Warning: noted but unhandled ioctl 0x3001 with no
size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x27 with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x7ff with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x25 with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x37 with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x17 with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: set address range perms: large range [0x2,
0x30020) (noaccess)
==61517== Warning: set address range perms: large range [0x7798000,
0x27797000) (noaccess)
==61517== Warning: set address range perms: large range
[0x1000600, 0x1010600) (noaccess)
==61517== Warning: noted but unhandled ioctl 0x19 with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: set address range perms: large range
[0x1010600, 0x1020600) (noaccess)
==61517== Warning: noted but unhandled ioctl 0x21 with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x1b with no size/direction hints.
==61517==This could cause spurious value errors to appear.
==61517==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
```
I'm also follwing this question[0] to generate Valgrind suppressions,
the program hangs again with same warnings. How can I use Valgrind
with CUDA correctly? Thanks in advance.
I'm using Ubuntu 18.04 + CUDA 9.1 + Valgrind 3.13.0.
Best regards,
Jiading Guo
[0]:
https://stackoverflow.com/questions/20593450/valgrind-and-cuda-are-reported-leaks-real
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
