Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
On 11/28/2012 02:56 PM, Philippe Waroquiers wrote: Currently, Valgrind does not provide a fully flexible way to indicate which leak kinds to show, which leak kinds to consider as an error, and which leak kinds to suppress. This is a.o. described in bugs 284540 and 307465. Here are the new command lines args: --show-leak-kinds=kind1,kind2,.. which leak kinds to show? [definite,possible] --errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors? [definite,possible] where kind is one of definite indirect possible reachable all none (note: old arguments are kept for backward compatibility). This is good as far as it goes. The presentation in the output from valgrind --help will matter, and so will the explanation given in the user manual. Just finding and understanding the new options is a significant barrier to usability. Try to write things so that applying grep gives good hints about where to read further. (This may include rewriting _other_ pieces in order to reduce false positive usage of key words.) More generally, why isn't this controllable by a loadable Python module, complete with defaults (including a complete default error handling module) and introspection? There should be ways to find all existing suppressions, how many times each one has been applied so far, the current traceback, the type of the current error, etc. If coregrind doesn't want to deal with Python, then have gdb do it. -- -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] massif only produces one snapshot with 0 memory use
Can you try with -v and/or with --trace-redir=yes ? That might give some lights about the problem ? I used both options and it produced the following output. Thanks for taking the time to look at this. ==9674== Massif, a heap profiler ==9673== Copyright (C) 2003-2012, and GNU GPL'd, by Nicholas Nethercote ==9673== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==9673== Command: ./MyProg ==9673== --9673-- Valgrind options: --9673----tool=massif --9673----soname-synonyms=somalloc=NONE --9673----trace-redir=yes --9673---v --9673-- Contents of /proc/version: --9673-- Linux version 2.6.18-308.11.1.el5 (mockbu...@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Tue Jul 10 08:48:43 EDT 2012 --9673-- Arch and hwcaps: AMD64, amd64-sse3-cx16 --9673-- Page sizes: currently 4096, max supported 4096 --9673-- Valgrind library directory: /home/twiser/programs/valgrind-3.8.1/lib/valgrind --9673-- Massif: alloc-fns: --9673-- Massif: malloc --9673-- Massif: __builtin_new --9673-- Massif: operator new(unsigned) --9673-- Massif: operator new(unsigned long) --9673-- Massif: __builtin_vec_new --9673-- Massif: operator new[](unsigned) --9673-- Massif: operator new[](unsigned long) --9673-- Massif: calloc --9673-- Massif: realloc --9673-- Massif: memalign --9673-- Massif: posix_memalign --9673-- Massif: valloc --9673-- Massif: operator new(unsigned, std::nothrow_t const) --9673-- Massif: operator new[](unsigned, std::nothrow_t const) --9673-- Massif: operator new(unsigned long, std::nothrow_t const) --9673-- Massif: operator new[](unsigned long, std::nothrow_t const) --9673-- Massif: ignore-fns: --9673-- Massif: empty --9673-- --9673---- REDIR STATE after VG_(redir_initialise) -- --9673---- ACTIVE -- --9673-- 0xff60 (??? ) R- (.0) 0x3801c013 ??? --9673-- 0xff600400 (??? ) R- (.0) 0x3801c01d ??? --9673-- 0xff600800 (??? ) R- (.0) 0x3801c027 ??? --9673-- --9673-- Reading syms from /home/twiser/code/MyProg/build/MyProg --9673--svma 0x400190, avma 0x400190 --9673--object doesn't have a dynamic symbol table --9673-- warning: DiCfSI 0x1f80056b2f0 .. 0x1f80056b442 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x1f80056b443 .. 0x1f80056b444 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x1f80056b445 .. 0x1f80056b445 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b4f0 .. 0x2900056b4f1 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b4f2 .. 0x2900056b4f5 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b4f6 .. 0x2900056b6d6 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6d7 .. 0x2900056b6d8 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6d9 .. 0x2900056b6da outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6db .. 0x2900056b6dc outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6dd .. 0x2900056b6dd outside mapped rw segments (NONE) --9673-- --9673---- REDIR STATE after VG_(redir_notify_new_DebugInfo) -- --9673--TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673---- ACTIVE -- --9673-- 0xff60 (??? ) R- (.0) 0x3801c013 ??? --9673-- 0xff600400 (??? ) R- (.0) 0x3801c01d ??? --9673-- 0xff600800 (??? ) R- (.0) 0x3801c027 ??? --9673-- --9673-- Reading syms from /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673--svma 0x003800, avma 0x003800 --9673--object doesn't have a dynamic symbol table --9673-- --9673---- REDIR STATE after VG_(redir_notify_new_DebugInfo) -- --9673--TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673--TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673---- ACTIVE -- --9673-- 0xff60 (??? ) R- (.0) 0x3801c013 vgPlain_amd64_linux_REDIR_FOR_vgettimeofday --9673-- 0xff600400 (??? ) R- (.0) 0x3801c01d vgPlain_amd64_linux_REDIR_FOR_vtime --9673-- 0xff600800 (??? ) R- (.0) 0x3801c027 vgPlain_amd64_linux_REDIR_FOR_vgetcpu --9673-- --9673-- Scheduler: using generic scheduler lock implementation. ==9673== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9673-by-twiser-on-twiser-d-01 ==9673== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-9673-by-twiser-on-twiser-d-01 ==9673== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-9673-by-twiser-on-twiser-d-01 ==9673== ==9673== TO CONTROL THIS PROCESS USING vgdb (which you probably ==9673== don't want to do,
[Valgrind-users] mmap fail when running valgrind massif
Hi I work with a software that uses boost memory mapping and seems that I can't run it inside massif nor memcheck, the error is: (boost::interprocess::mapped_region::mapped_regionboost::interprocess::file_mapping(boost::interprocess::file_mapping const, boost::interprocess::mode_t, long, unsigned long, void const*)+0x513) [0x11f9e2f] Without valgrind everything works fine, it tries to map a file of 20GB or so, might this be the reason? Pedro. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
On Thu, 2012-11-29 at 08:44 +0100, David Faure wrote: Here are the new command lines args: --show-leak-kinds=kind1,kind2,.. which leak kinds to show? [definite,possible] --errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors? [definite,possible] where kind is one of definite indirect possible reachable all none This sounds good, but I'm missing one piece of information: what will the default values be? The default values are indicated in [] in the --help above. These default values are backward compatible with the current default values. It would be good for this to have sane defaults, so that most users don't actually need to specify these options. Would this mean show for possible and error for definite? It is expected that keeping the same default behaviour as today is the sane default. Philippe -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds
On Thu, 2012-11-29 at 06:25 -0800, John Reiser wrote: This is good as far as it goes. The presentation in the output from valgrind --help will matter, and so will the explanation given in the user manual. Just finding and understanding the new options is a significant barrier to usability. Try to write things so that applying grep gives good hints about where to read further. (This may include rewriting _other_ pieces in order to reduce false positive usage of key words.) The patch contains the --help and the updates to the manual. Feedback welcome ... More generally, why isn't this controllable by a loadable Python module, complete with defaults (including a complete default error handling module) and introspection? There should be ways to find all existing suppressions, how many times each one has been applied so far, the current traceback, the type of the current error, etc. If coregrind doesn't want to deal with Python, then have gdb do it. Integrate a Python interpreter inside Valgrind seems quite a lot of work. It is not clear to me if the possible usage(s) would justify it. Using the python interpreter in GDB (via the Valgrind gdbsrv) is ok as long as it accesses the guest process data. I do not know a way to persuade GDB that the process also has Valgrind tool data (and code). Philippe -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] massif only produces one snapshot with 0 memory use
On Thu, 2012-11-29 at 07:30 -0800, Wiser, Tyson wrote: Can you try with -v and/or with --trace-redir=yes ? That might give some lights about the problem ? I used both options and it produced the following output. Thanks for taking the time to look at this. There is an unexpected (or rather missing) behaviour in the trace you have provided. You should find lines such as: --3143-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so ... --3143-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_massif-amd64-linux.so Without these, there is no chance to have replacements being done. Maybe an installation problem ? Can you try: valgrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes \ -v -v -v -d -d -d ./MyProg 21 | grep -i preload This should give something like: --31179:2:initimgpreload_string: --31179:2:initimg /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so:/home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_massif-amd64-linux.so --31179-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so --31179--TOPSPECS of soname NONE filename /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so --31179-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_massif-amd64-linux.so You should then check that the files referenced by initimg exist and have correct permissions (typically -rwxr-xr-x). If initimg is correct and files are existing and have correct permission, then mystery is increasing. You could try the same with memcheck and see if the preload for memcheck is working (and malloc replacement is properly done). You could also verify if the regression test for the static malloc replacement works by doing: cd memcheck/tests/ make static_malloc algrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes \ -v -v -v -d -d -d ./static_malloc 21 | grep -i preload Philippe -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] mmap fail when running valgrind massif
On Thu, 2012-11-29 at 17:31 +0100, Pedro Larroy wrote: Without valgrind everything works fine, it tries to map a file of 20GB or so, might this be the reason? Yes, it might be the reason. Try to reduce the size to e.g. 1GB and see if it works. -v -v -v -d -d -d args will also activate tracing for the VAlgrind address space manager. This trace could explain why 20Gb are not mappable. Also, you should try with the last version (3.8.1). Philippe -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
