[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows up to 50 frames

[Robin Kuzmin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=199468

--- Comment #6 from Robin Kuzmin  ---
Makes sense for me.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows up to 50 frames

[Robin Kuzmin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=199468

--- Comment #4 from Robin Kuzmin  ---
I have run through this discussion more thoroughly. My understanding how
valgrind works (or should work) has changed. Here is my vision.

In order to avoid multiple reports of the same error, valgrind uses top 4 stack
frames to common up the errors (see description of "--num-callers" at
http://valgrind.org/docs/manual/manual-core.html#manual-core.options). 

Valgrind (memcheck) deals with (at least) 2 types of the stack traces:

1. The Short-term Stack Traces. They are reported immediately upon error, e.g.
when the analyzed program accesses outside the heap-allocated block. At this
stage the entire stack trace can be used for suppressions (both for applying
the suppressions and for generating the suppression with --gen-suppressions).
After suppressions, if/when reporting these stack traces to the console the top
--num-callers frames are (or can be) printed. Then these stack traces are (or
can be) forgotten by valgrind (and only the top 4 stack frames are (or can be)
saved to common up the errors). Thus for the Short-term Stack Traces there is
no need for the suppressions to depend on the --num-callers. Implementing this
mechanism will be relatively cheap (the price will be an INsignificant lower
down in performance and INsignificant (and short-term) increase in resource
requirements).

2. The Long-term Stack Traces. These stack traces valgrind has to store in
memory for a long period of time, and potentially till the end of the analyzed
program. E.g. when the analyzed program makes an allocation, the allocation
stack trace has to be kept until the CORRECT deallocation (if the CORRECT
deallocation Ever happens) or until the termination (if the CORRECT
deallocation Never happens). For the Long-term Stack Traces valgrind can try to
APPLY suppressions immediately (upon allocation) to the entire stack trace. If
any of the suppressions is applicable then the top 4 stack frames are stored to
common up the errors (and the stack trace can be marked as "to be suppressed by
suppression N"), otherwise (none of the suppressions apply) the number of stack
frames to be saved depends on the --gen-suppressions. If "no" then the
--num-callers stack frames are stored, otherwise the entire stack trace is
stored (and the entire stack trace is used for generating the suppression (if
the CORRECT deallocation never happens), and only the --num-callers stack
frames are used for reporting the error to the console).

Thus the suppressions might be independent of the --num-callers.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows up to 50 frames

[Robin Kuzmin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=199468

--- Comment #3 from Robin Kuzmin  ---
You wrote: If suppressions would have to be done without taking --num-callers
into account, then it means that all errors stacktraces would have to be first
recorded without limit, and then after (unsuccesful) suppression matching, the
frames exceeding --num-callers would have to be dropped.

That closely describes my intuitive expectation about how Valgrind should work
(at least based on what I read for  --num-callers at
http://valgrind.org/docs/manual/manual-core.html#manual-core.options). I
expected the suppressions to work always, regardless of --num-callers. And I
expected the --num-callers to be considered ONLY WHEN PRINTING the stack trace
to console. And I expected that internally Valgrind saves the entire stack
trace for every error.

Now I understand that the implementation that corresponds to my expectation
would work much slower, require much more resources (for stack traces), and
will hardly work ok for the endless recursion (endless stack trace until the
stack overflow).

Thus I recommend at least 2 settings for the length of the stack trace:
+ the first setting specifies how many stack frames valgrind saves internally,
the same setting specifies how many stack frames are used for the suppressions
(currently this is done using the  --num-callers). By default this setting
should be relatively high (e.g. 50+);
+ the second setting specifies how many stack frames valgrind prints to the
console when reporting the errors. By default this setting should be relatively
low (e.g. 12-).

And the documentation should clearly describe which setting determines what,
and from the documentation it should be clear that the suppression might not
suppress for short "first setting".

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows up to 50 frames

[Robin Kuzmin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=199468

Robin Kuzmin  changed:

   What|Removed |Added

 CC||kuzmin.ro...@gmail.com

--- Comment #1 from Robin Kuzmin  ---
I have the same issue.
I have a suppression:
{
   google::protobuf::Message::PrintDebugString() const (text_format.cc:110)
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:_Znwm
   ...
   fun:_ZNK6google8protobuf7Message11DebugStringEv
   fun:_ZNK6google8protobuf7Message16PrintDebugStringEv
   ...
}
This suppression is ignored for "--num-callers=20", but works fine (suppresses)
for "--num-callers=40". 
I didn't expect the suppressions to depend on "--num-callers".

-- 
You are receiving this mail because:
You are watching all bug changes.