valgrind

valgrind, profiling timer expired?

荒凉一梦 提交于 2019-12-05 01:45:17
I try to profile a simple c prog using valgrind: [zsun@nel6005001 ~]$ valgrind --tool=memcheck ./fl.out ==2238== Memcheck, a memory error detector ==2238== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2238== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2238== Command: ./fl.out ==2238== ==2238== ==2238== HEAP SUMMARY: ==2238== in use at exit: 1,168 bytes in 1 blocks ==2238== total heap usage: 1 allocs, 0 frees, 1,168 bytes allocated ==2238== ==2238== LEAK SUMMARY: ==2238== definitely lost: 0 bytes in 0 blocks ==2238== indirectly lost: 0 bytes in 0

Memory leak reported by valgrind in dlopen?

半腔热情 提交于 2019-12-05 01:13:22
I've been debugging some app lately with valgrind, and I'm getting very weird reports from dlopen . ==1987== 32 bytes in 1 blocks are still reachable in loss record 1 of 2 ==1987== at 0x4C24477: calloc (vg_replace_malloc.c:418) ==1987== by 0x570F31F: _dlerror_run (dlerror.c:142) ==1987== by 0x570EEE0: dlopen@@GLIBC_2.2.5 (dlopen.c:88) <my call to dlopen> ==1987== ==1987== 264 bytes in 1 blocks are still reachable in loss record 2 of 2 ==1987== at 0x4C25153: malloc (vg_replace_malloc.c:195) ==1987== by 0x400CD44: _dl_map_object_deps (dl-deps.c:506) ==1987== by 0x4012DA2: dl_open_worker (dl-open

Valgrind gives an error for nearly everything (Warning: client switching stacks?)

荒凉一梦 提交于 2019-12-04 22:30:23
I'm corrupting memory somehow because my program crashes without error at random places. I'm using valgrind with --leak-check=full , compiling with -O0 -g , and the very first problem it detects is the first line in int main() cout << "reading file" << endl; with ==5089== Warning: client switching stacks? SP change: 0x7ff0004f8 --> 0x7feb7de10 ==5089== to suppress, use: --max-stackframe=4728552 or greater ==5089== Invalid write of size 8 ==5089== at 0x41E107: main (Dgn.cpp:2833) ==5089== Address 0x7feb7de08 is on thread 1's stack It goes on with ==5089== Invalid read of size 8 ==5089== at

valgrind error and ucontext. Why “Use of uninitialised value of size 8”?

被刻印的时光 ゝ 提交于 2019-12-04 20:39:58
问题 I have been trying to understand why valgrind complains about "Use of uninitialised value of size 8" for this small test program that uses ucontexts. It is basically a program that creates "n_ucs" ucontexts and switches over them for "max_switch" times. I understand the "Warning: client switching stacks?" (which is basically what the program all about), but I can't really make sense to all the "Use of uninitialised value of size 8" I would like to get some help understanding if Valgrind

free(): invalid next size (normal) on fclose. But not when Valgrind runs [duplicate]

南笙酒味 提交于 2019-12-04 16:29:39
This question already has an answer here: Facing an error “*** glibc detected *** free(): invalid next size (fast)” 2 answers The code below breaks on the fclose() call. void output_gauss_transform(char* filename, char* mode, double** T, double shift, int len) { FILE* fp; printf("Outputting gauss transform to %s.\n", filename); if ((fp = fopen(filename, mode)) == NULL){ perror("Could not open file"); return; } int i; for (i = 0; i < len; ++i) { fprintf(fp, "%lf %lf\n", T[0][i], T[1][i] + shift); } if (fclose(fp)){ printf("error closing\n"); } } glibc gives me this error, along with the memory

How do you interpret cachegrind output for caching misses?

会有一股神秘感。 提交于 2019-12-04 16:20:13
问题 Out of curiosity I ran coded up several different versions of matrix Multiplication and ran cachegrind against it. In my results below, I was wondering which parts were L1,L2,L3 misses and references and what it all really means? Below is my code for the matrix multiplications also, in case anyone needs that. #define SLOWEST ==6933== Cachegrind, a cache and branch-prediction profiler ==6933== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al. ==6933== Using Valgrind-3.8.1

Valgrind: invalid read of size 4 -> sigsegv, works fine without valgrind and in visual studio

时光毁灭记忆、已成空白 提交于 2019-12-04 16:11:22
问题 I have implemented a compression algorithm (using huffman coding) which uses a priority queue of nodes (a struct i defined). Now, when i just run the code in linux or in visual studio, everything works fine. When I check for memory leaks in visual studio, none are given. The problem now is, when I use valgrind to analyse my program, it terminates with signal 11 (sigsegv). The first error encountered is an 'invalid read of size 4' in the method delete min. Other errors after that are: Adress

Should I use Helgrind or DRD for thread error detection?

别说谁变了你拦得住时间么 提交于 2019-12-04 15:13:11
问题 Looks like Valgrind has two tools that both do thread error detection: Helgrind and DRD. These tools are substantially similar. My primary question is: when should I use one instead of the other to check my multi-threaded code? More broadly, why are there two tools? I assume they aren't entirely redundant. What are the important differences? Should I generally plan on running my code through both tools? 回答1: While Helgrind can detect locking order violations, for most programs DRD needs less

Why electric fence/Valgrind is unable to catch this buffer-overflow issue?

穿精又带淫゛_ 提交于 2019-12-04 14:46:57
问题 I have created a buggy program - buggy.c - this is a buffer-overflow scenario for buffer t. You can see that I am writing more than 5 indexes. It works fine. It never throws me an error. I was wondering, why is it like that? I tried even Valgrind, this also couldn't find this issue. Can you tell me please what is the issue here? void buffer_overflow(void) { int t[5]; int i = 0; for(i = 0; i<=7; i++) { t[i] = i; } /** this will cause buffer overflow **/ printf("Memory_overflow_completed\r\n");

Ubuntu System Monitor and valgrind to discover memory leaks in C++ applications

孤街浪徒 提交于 2019-12-04 12:09:59
问题 I'm writing an application in C++ which uses some external open source libraries. I tried to look at the Ubuntu System Monitor to have information about how my process uses resources, and I noticed that resident memory continues to increase to very large values (over 100MiB). This application should run in an embedded device, so I have to be careful. I started to think there should be a (some) memory leak(s), so I'm using valgrind. Unfortunately it seems valgrind is not reporting significant