https://bugs.kde.org/show_bug.cgi?id=199468
--- Comment #3 from Robin Kuzmin <kuzmin.ro...@gmail.com> --- 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.
