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