|
From: Philippe W. <phi...@sk...> - 2009-05-06 20:38:52
|
The default value for leak-resolution is set to low. The default value for the nr of callers in a stack trace is 12 (so significantly higher than the 2 entries corresponding to the medium leak resolution). When a leak is reported, it is reported with a full stack trace (e.g. 12 callers) but this report "merges" the leaks created by various other stack traces only having the first 2 callers in common. At work, this has created confusion (and some doubts about the tool behaviour/quality) e.g. because "this stack trace is only called once and allocates only one block, how can it leak that much blocks ?" or "I fixed the only leak(s) reported, and now I have other leaks being reported in other stack traces." It looks to me that leak-resolution=high will be a better default as it will not confuse users. If a user really needs to combine various stack traces in one stack trace, then resolution low or medium can then be given. NB: due to this confusion, at work, we switched to leak-resolution=high, triggering a quadratic behaviour in the leak report code. This bug #191182 has been fixed in 3.5.0 SVN. To my knowledge, other leak search tools (purify, wdb) always report full stack traces for leaks (or at least according to the num-callers equivalent). => I believe default value high resolution is better. NB: I believe the valgrind user manual description of leak-resolution wrongly says the default value for the nr of callers is 4 (I think it is 12). |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-07 00:23:56
|
On Thu, May 7, 2009 at 6:38 AM, Philippe Waroquiers
<phi...@sk...> wrote:
> The default value for leak-resolution is set to low.
> The default value for the nr of callers in a stack trace is 12 (so significantly higher than the 2 entries corresponding
> to the medium leak resolution).
> When a leak is reported, it is reported with a full stack trace (e.g. 12 callers)
> but this report "merges" the leaks created by various other stack traces only having the first 2 callers
> in common.
>
> At work, this has created confusion (and some doubts about the tool behaviour/quality)
> e.g. because "this stack trace is only called once and allocates only one block, how can it leak that much blocks ?"
> or "I fixed the only leak(s) reported, and now I have other leaks being reported in other stack traces."
>
> It looks to me that leak-resolution=high will be a better default as it will not confuse users.
> If a user really needs to combine various stack traces in one stack trace, then resolution low or medium
> can then be given.
I agree with this. The rationale in the docs is:
<para>For hardcore leak debugging, you probably want to use
<option>--leak-resolution=high</option> together with
<option>--num-callers=40</option> or some such large number. Note
however that this can give an overwhelming amount of information,
which is why the defaults give less information.</para>
but I can see it would be confusing, especially since it is *different
to the way other reports are merged*.
If a user gets lots of leak reports with --leak-resolution=high, then
that's because the program has lots of leaks which will need to be
fixed! Pretending otherwise doesn't make their lives easier. Julian?
> NB: I believe the valgrind user manual description of leak-resolution wrongly says the default value for
> the nr of callers is 4 (I think it is 12).
This was fixed on the trunk, but not the 3.4.X branch. I've fixed it
there too, now.
Nick
|
|
From: Julian S. <js...@ac...> - 2009-05-07 08:54:46
|
> > It looks to me that leak-resolution=high will be a better default as it > > will not confuse users. If a user really needs to combine various stack > > traces in one stack trace, then resolution low or medium can then be > > given. > > I agree with this. The rationale in the docs is: > > <para>For hardcore leak debugging, you probably want to use > <option>--leak-resolution=high</option> together with > <option>--num-callers=40</option> or some such large number. Note > however that this can give an overwhelming amount of information, > which is why the defaults give less information.</para> > > but I can see it would be confusing, especially since it is *different > to the way other reports are merged*. I don't have a particularly strong opinion; if you want to change the default to high, then fine. The reason I set it the way it is is because of a feeling that it's better to present a small amount of info to the user and then say "I can show you more details if you want", then to flood the user with lots of different stack traces from the start. But perhaps a bad call. > If a user gets lots of leak reports with --leak-resolution=high, then > that's because the program has lots of leaks which will need to be > fixed! Pretending otherwise doesn't make their lives easier. Julian? Well, regardless of the setting of this, we always print the totals for blocks and bytes leaked (in various ways). So it's not like we're pretending the program is less leaky than it really is. J |
|
From: Philippe W. <phi...@sk...> - 2009-05-07 05:38:51
|
> > It looks to me that leak-resolution=high will be a better default as it will not confuse users.
> I agree with this. The rationale in the docs is:
Note that the command line summary help text (3.4.1) is also somewhat confusing:
--leak-resolution=low|med|high how much bt merging in leak check [low]
Intuitively (at least for a french speaking person :), a "low how much bt merging"
will merge less stack traces than a "high" bt merging.
Maybe the help text should be changed to (assuming the default changes):
'precision and quantity of leak backtraces reporting [high]'
This explains you get a low precision and a low quantity
or a high precision and a high quantify
|
|
From: Julian S. <js...@ac...> - 2009-05-07 23:12:50
|
On Thursday 07 May 2009, Philippe Waroquiers wrote:
> > > It looks to me that leak-resolution=high will be a better default as it
> > > will not confuse users.
> >
> > I agree with this. The rationale in the docs is:
>
> Note that the command line summary help text (3.4.1) is also somewhat
> confusing: --leak-resolution=low|med|high how much bt merging in leak
> check [low]
>
> Intuitively (at least for a french speaking person :), a "low how much bt
> merging" will merge less stack traces than a "high" bt merging.
Hmm, it is indeed confusing. I never noticed that before.
What about
--leak-resolution=low|med|high
precision of stack traces in leak check [high]
I prefer not to mention "quantity" just in case confused users think
it is somehow related to the quantity of leaked memory.
J
|
|
From: Philippe W. <phi...@sk...> - 2009-05-08 20:40:09
|
> What about
>
> --leak-resolution=low|med|high precision of stack traces in leak check [high]
For me this is quite clear.
Another alternative would be to use the word differentiation
(because the printed stacks will be precise but not differentiated)
i.e.
--leak-resolution=low|med|high differentiation of stack traces in leak check [high]
Philippe
|
|
From: Julian S. <js...@ac...> - 2009-05-13 11:09:29
|
On Friday 08 May 2009, Philippe Waroquiers wrote: > Another alternative would be to use the word differentiation > (because the printed stacks will be precise but not differentiated) > i.e. > --leak-resolution=low|med|high differentiation of stack traces in > leak check [high] Yes, I think that's the best proposal so far. I'd go with that. J |