https://bugs.kde.org/show_bug.cgi?id=199468
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #2 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Robin Kuzmin from comment #1)
> 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".
I think that we have 2 different problems:
The bug speaks about the fact that a suppression is limited to 24 entries,
while the --num-callers can now (in valgrind 3.11) go up to 500.
Your problem is that a suppression works with 40 num callers, but does not
suppress
for 20 num callers. This is not abnormal: if for example
fun:_ZNK6google8protobuf7Message11DebugStringEv is at depth 30, when you use
--num-callers=20, then this function will not be recorded in the error
stacktrace and the suppression will not match.
This is because the logic is:
* first an error is made, with a stacktrace recorded as specified with
--num-callers
* after that, the suppression entries are tried.
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.
The original problem (suppressions limited to 24 entries while errors can
record up to 500 frames) is somewhat strange. I could not retrieve any comment
or svn log describing why
suppression entries are limited to 24 entries. --num-callers used to be limited
to 50.
If we increase the nr of entries in suppressions to 500 (the max value for
--num-callers),
this will however has as a side effect that --gen-suppressions will produce
bigger entries
while they were limited to 24 entries. I guess this is not a problem, as in any
case, for many suppression entries, 24 was already a lot (e.g. for suppression
entries intended to suppress errors in libraries)
--
You are receiving this mail because:
You are watching all bug changes.
