valgrind

is there any extension of valgrind, that can be used in the command window, that would help me know the time, in seconds, spent in each function in my C code? thanks =) Karoly Horvath For machine instruction profiling use valgrind's callgrind (also, cachegrind can do cache and branch prediction profiling which is quite nice). For time measurements use google's cpu profiler , it gives way better results than gprof. You can set sampling frequency and it can show the output as a nice annotated call graph. Valgrind isn't suited for measuring time, as running an application in valgrind distorts the

I looked for existing answers first and saw that Valgrind is everyone’s favorite tool for memory leak debugging on linux. Unfortunately Valgrind does not seem to work for my purposes. I will try to explain why. Constraints: The leak reproduces only in customer’s environment. Due to certain legal restrictions we have to work with existing binary. No rebuilds. In regular environment our application consumes ~10% CPU. Say, we can tolerate up to 10x CPU usage increase. Valgrind with default memcheck settings does much worse making our application unresponsive for long periods of time. What I need

While working with Valgrind tool, i need to log the details produced by valgrind tool. How can I accomplish that? I tried something like, valgrind a.out | test and valgrind a.out > test It gave just the program's output and not the valgrind memory error,leak information. Even i am getting like this if the program requires no user interaction (i.e. giving input). If the program need user input even that thing itself won't work. How can I do this? Vasileios Lekakis valgrind --log-file="filename" By default, Valgrind writes its output to stderr. So you need to do something like: valgrind a.out >

I wrote a small piece of code like this: template <class T> void test() { T* ptr = nullptr; ptr = (T*)malloc(1 * sizeof(T)); new ((void*)ptr) T(T()); ptr = (T*)realloc(ptr, 2 * sizeof(T)); new ((void*)(ptr + 1)) T(T()); (ptr)->~T(); (ptr + 1)->~T(); free(ptr); } struct foo { foo() : ptr(malloc(10)) {} ~foo() { free(ptr); } void* ptr; }; int main() { test<int>(); // this is ok test<foo>(); // this is ok test<std::string>(); // memory error :( return 0; }; When T is [int] or [foo], everything works fine. But using [std::string] as T causes valgrind to report memory errors like this: ==18184==

I'm getting valgrind errors when attempting to pclose() a pipe previously open with popen() . The errors occur on Mac OS X, but not on Linux. Consider the following example: #include <stdlib.h> #include <stdio.h> int main() { FILE *fp; char buf[4096]; if (!(fp = popen("ls", "r"))) exit(-1); while (fscanf(fp, "%s", buf) == 1) printf("%s\n", buf); pclose(fp); return 0; } I get the following valgrind errors on a Mac (OS X 10.6.7, valgrind version 3.6.0), except if I remove the pclose() call: ==21455== Conditional jump or move depends on uninitialised value(s) ==21455== at 0xB1992: pclose (in /usr

While working on my school project I keep receiving following error from Valgrind after compiling my project on Unix school server and being unable to run the program, as I receive "Segmentation fault: 11". ==95183== Memcheck, a memory error detector ==95183== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==95183== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==95183== Command: ./Euler ==95183== ==95183== Invalid read of size 8 ==95183== at 0x400B65: GInit (Euler.c:64) ==95183== by 0x400DD1: main (Euler.c:118) ==95183== Address 0x1786100 is 0 bytes after

I'm using the following code... 169: const char *title = Title.c_str(); 170: glutCreateWindow(title); ... Valgrind gives me the following ... ==28841== Conditional jump or move depends on uninitialised value(s) ==28841== at 0x6FF7A4C: (within /usr/lib64/libGLcore.so.180.44) ==28841== by 0x6FF81F7: (within /usr/lib64/libGLcore.so.180.44) ==28841== by 0x7289B36: (within /usr/lib64/libGLcore.so.180.44) ==28841== by 0x728A757: _nv000133gl (in /usr/lib64/libGLcore.so.180.44) ==28841== by 0x4EAB9E9: (within /usr/lib64/libGL.so.180.44) ==28841== by 0x4EAEA81: (within /usr/lib64/libGL.so.180.44) =

I'm running valgrind on my program and I'm getting the following output (I'm gonna omit the 83 errors above this, let me know if I should include them in the log): ==9723== LEAK SUMMARY: ==9723== definitely lost: 0 bytes in 0 blocks ==9723== indirectly lost: 0 bytes in 0 blocks ==9723== possibly lost: 4,676 bytes in 83 blocks ==9723== still reachable: 88,524 bytes in 579 blocks ==9723== suppressed: 0 bytes in 0 blocks ==9723== Reachable blocks (those to which a pointer was found) are not shown. ==9723== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==9723== ==9723== For