https://bugs.kde.org/show_bug.cgi?id=199468
--- Comment #5 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Robin Kuzmin from comment #4) > 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. For what you call 'long term stacktraces" : capturing a big stacktrace is costly by itself. A lot of effort was spent to optimise this, but still this is costly. So, always capturing an (unlimited) stack trace is not desirable. But applying the suppression entries is even (a lot) more costly. E.g. it implies to translate an IP address into a function name. A lot of effort was spent already to make these suppression matching faster (e.g. using lazy completers, see m_errormgr.c is_suppressible_error function). But such suppression matching can clearly not be done all the time (e.g. for all allocations; in memcheck or in some tools such as helgrind, even for all memory accesses). So, what you suggest cannot be implemented without impacting significantly the performance. With that in mind, I think the best approach for you is just to use suppressions that works properly with the --num-callers you are using. For what concerns the original problem (suppression entries limited to 24 entries): I guess we could/should use the same max sze as the max value fo r--num-callers -- You are receiving this mail because: You are watching all bug changes.
