valgrind

I am currently working on an application which involves lots and lots of calls to blas routines. Routinely checking for memory leaks I discovered, that I am loosing bytes in a dgemm call. The call looks like this: // I want to multiply 2 nxn matrices and put the result into C - an nxn matrix double zero = 0.0; double one = 1.0; double n; // matrix dimension char N = 'N'; dgemm_(&N, &N, &n, &n, &n, &one, A, &n, B, &n, &zero, C, &n); A,B and C are double fields of size n*n. The valgrind output is: ==78182== 18 bytes in 1 blocks are definitely lost in loss record 2 of 30 ==78182== at 0xB936:

I use getpwnam_r to handle client connections in my programs. Sadly enough, it seems to allocate a buffer it never frees. The relevant valgrind output: ==15774== 536 (104 direct, 432 indirect) bytes in 2 blocks are definitely lost in loss record 1 of 3 ==15774== at 0x4C24CFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==15774== by 0x5143B5A: nss_parse_service_list (in /lib64/libc-2.10.1.so) ==15774== by 0x51442E6: __nss_database_lookup (in /lib64/libc-2.10.1.so) ==15774== by 0x57BE35F: ??? ==15774== by 0x57BF3F6: ??? ==15774== by 0x51014D2: getpwnam_r@@GLIBC_2.2.5 (in

Assume I have a C program (running under Linux) which manipulates many data structures, some complex, several of which can grow and shrink but should not in general grow over time. The program is observed to have a gradually increasing RSS over time (more so than can be explained by memory fragmentation). I want to find what is leaking. Running under valgrind is the obvious suggestion here, but valgrind (with --leak-check=full and --show-reachables=yes ) shows no leak. I believe this to be because the data structures themselves are correctly being freed on exit, but one of them is growing

I'm very new to C, and can't seem to figure out what's wrong with the following code. int main() { char filen[] = "file.txt"; FILE *file = fopen ( filen, "r" ); if ( file != NULL ) { char line [ 128 ]; while ( fgets ( line, sizeof line, file ) != NULL ) /* read a line */ { int i; char *result; for(i=0; i< NUM;i++) { char *rep; rep = (char *) malloc (sizeof(mychars[i][0])); strcpy(rep, mychars[i][0]); char *with; with = (char *) malloc (sizeof(mychars[i][1])); strcpy(with, cgichars[i][1]); result = (char *) malloc (sizeof(char) * 128); result = str_replace(line, rep, with); } fputs(result,

I have seen some of the post regarding valgrind but not single post helped me in understanding interpretation of valgrind output. I ran two programs with valgrind (Both having memory leaks) Sample Output for Test 1 ==20422== LEAK SUMMARY: ==20422== definitely lost: 448 bytes in 3 blocks ==20422== indirectly lost: 786,460 bytes in 1 blocks ==20422== possibly lost: 1,576,052 bytes in 46 blocks ==20422== still reachable: 1,077,107 bytes in 2,333 blocks ==20422== suppressed: 0 bytes in 0 blocks ==20422== Rerun with --leak-check=full to see details of leaked memory ==20422== ==20422== For counts of

I'm trying to understand how to correctly release memory when I am finished with a GTK widget, for example if I need to create and destroy many widgets. However, valgrind seems to indicate a memory leak regardless of what I try. I've looked at other questions, including one that lists a valgrind supression file for GTK, but it didn't change the result. Here's the simplest code snippet to reproduce my issue: #include "gtk/gtk.h" int main() { GtkWidget * widget = gtk_fixed_new(); g_object_ref(widget); g_object_ref_sink(widget); // remove floating reference, and own this object ourselves g_object

Linux c/c++ 上常用内存泄露检测工具有 valgrind, Rational purify 。 Valgrind 免费。 Valgrind 可以在 32 位或 64 位 PowerPC/Linux 内核上工作。 Valgrind 工具包包含多个工具，如 Memcheck,Cachegrind,Helgrind, Callgrind ， Massif 。下面分别介绍个工具的作用： Memcheck 工具主要检查下面的程序错误： • 使用未初始化的内存 (Use of uninitialised memory) • 使用已经释放了的内存 (Reading/writing memory after it has been free ’ d) • 使用超过 malloc 分配的内存空间 (Reading/writing off the end of malloc ’ d blocks) • 对堆栈的非法访问 (Reading/writing inappropriate areas on the stack) • 申请的空间是否有释放 (Memory leaks – where pointers to malloc ’ d blocks are lost forever) • malloc/free/new/delete 申请和释放内存的匹配 (Mismatched use of