valgrind

I have a very simple CUDA component in my application. Valgrind reports a lot of leaks and still-reachables, all related to the cudaMalloc calls. Are these leaks real? I call cudaFree for every cudaMalloc . Is this valgrind's inability to interpret GPU memory allocation? If these leaks are not real, can I suppress them and have valgrind only analyse the non-gpu part of the application? extern "C" unsigned int *gethash(int nodec, char *h_nodev, int len) { unsigned int *h_out = (unsigned int *)malloc(sizeof(unsigned int) * nodec); char *d_in; unsigned int *d_out; cudaMalloc((void**) &d_in,

The documentation for the Valgrind thread error detection tool Helgrind, found here warns that, if you use GCC to compile your OpenMP code, GCC's OpenMP runtime library ( libgomp.so ) will cause a chaos of false positive reports of data races, because of its use of atomic machine instructions and Linux futex system calls instead of POSIX pthreads primitives. It tells you that you can solve this problem, however, by recompiling GCC with the --disable-linux-futex configuration option. So I tried this. I compiled and installed to a local directory ( ~/GCC_Valgrind/gcc_install ) a new GCC version

I have a code which works perfect in serial but with mpirun -n 2 ./out it gives the following error: ./out': malloc(): smallbin double linked list corrupted: 0x00000000024aa090 I tried to use valgrind such as: valgrind --leak-check=yes mpirun -n 2 ./out I got the following output: ==3494== Memcheck, a memory error detector ==3494== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==3494== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==3494== Command: mpirun -n 2 ./out ==3494== Grid_0/NACA0012.msh Grid_0/NACA0012.msh >>> Number of cells: 7734 >>> Number of

Today I installed valgrind on my Mac os x 10.6 and tried to test it out. And it turned out to be weird memory leaks in the system. What I did was just create simple c file that get some heap memory and immediately free it. When I ran valgrind it showed something like this Realfrees-MacBook-Pro:C Realfree$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./a.out ==2621== Memcheck, a memory error detector ==2621== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2621== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==2621== Command: ./a.out =

On Linux, FreeBSD and other systems I have valgrind for checking for memory errors like invalid reads and similar. I really love valgrind. Now I have to test code on Solaris/OpenSolaris and can't find a way to get information on invalid reads/writes in an as nice way (or better ;-)) as valgrind there. When searching for this on the net I find references to libumem , but I get only reports about memory leaks there, not invalid access. What am I missing? The dbx included with the Sun Studio compilers includes memory access checking support in its "Run Time Checking" feature (the check subcommand

There comes a time in life of a developer when one gets this error valgrind: failed to start tool 'memcheck' for platform 'x86-linux' I do not see myself as an expert Valgrind user, but I understand output of Valgrind enough to catch memory leaks in my C programs. The other day I launched a personal project in assembly language and used standard C memory routines (calloc, realloc, free) for its memory requirements. The program grew complex and I wanted to be sure I am not leaking any memory (and also to be sure I am leaking memory where I know I am leaking at that stage - amid development),

I want to use Valgrind 3.7.0 to find memory leaks in my Java native code. I'm using jdk1.6.0._29. To do that, I have to set the --trace-children=yes flag. Setting that flag, I no longer can run valgrind on any java application, even a command like: valgrind --trace-children=yes --smc-check=all java -version will get the error message: Error occurred during initialization of VM Unknown x64 processor: SSE2 not supported I've seen this link: https://bugs.kde.org/show_bug.cgi?id=249943 , but it was not useful. Running the program without Valgrind or without the --trace-children flag is fine. Does

By checking with valgrind, I see that 5 blocks of memory were not freed after terminating my program, but they are still reachable. Do I need to be bothered by it? And how it happens? zhanwu@gelata:~/sandbox$ valgrind ./a.out ==2430== Memcheck, a memory error detector ==2430== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2430== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2430== Command: ./a.out ==2430== Hello world! Thread1 returns 1 Thread2 returns 10 Thread3 returns 10 ==2430== ==2430== HEAP SUMMARY: ==2430== in use at exit: 1,590 bytes in 5