Re: [Valgrind-users] RFC: more flexible way to show or count as error or suppress leak kinds

2012-11-30 Thread David Faure
On Thursday 29 November 2012 23:35:03 Philippe Waroquiers wrote:
 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.

Ah, I thought this was the list of possible values in that field. OK.

  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.

I thought this was a good opportunity to improve upon today's behavior and not 
error for possible leaks, only show  them. But I'm no expert on the matter.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5


--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
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

2012-11-30 Thread Philippe Waroquiers
On Fri, 2012-11-30 at 06:56 -0800, Wiser, Tyson wrote:

 I'm not sure how to interpret these results.  Does all this look OK?
Yes, it looks similar to what I see here.

To see that the whole replacement thing is working,
the command
  valgrind --tool=memcheck --soname-synonyms=somalloc=NONE ./static_malloc

should produce lines telling that the heap was used e.g.
  ==14445==   total heap usage: 2 allocs, 1 frees, 133 bytes allocated
  ...
  ==14445==definitely lost: 10 bytes in 1 blocks

If the same lines appears in your case, it means the memcheck replacement
works on static_malloc. If the replacement is not done (e.g. 
by using --soname-synonyms=somalloc=FOO), then you rather have
  ==29278==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated

With massif correct replacement, it should produce a massif.out.x
file telling some memory was allocated.

If that works with the static_malloc program but not with your program,
then better file a bug in bugzilla, attaching the full output
of -v -v -v -d -d -d --trace-redir=yes.
You could also verify that your program is doing a call to malloc
(or similar function), find the address of this function 
A correct redirection for malloc will look like
   --24545-- REDIR: 0x4004e4 (malloc) redirected to 0x4c25c59 (malloc)
(with the malloc original address being found by:
   nm static_malloc | grep malloc
   004004e4 T malloc

Philippe




--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users