|
From: Philippe W. <phi...@sk...> - 2016-08-26 11:14:53
|
Hello, https://bugs.kde.org/show_bug.cgi?id=199468 complains that valgrind suppressions entries are limited to 25, which is smaller than the max size for --num-callers (Florian changed it to 500 in 2012). This difference between the 2 max gives 2 limitations: 1. You cannot write a suppression entry that precisely match the produced backtrace, when using --num-callers > 25 2. When using --gen-suppressions=yes, the generated suppressions are limited to 25 entries. The fix is easy : remove VG_MAX_SUPP_CALLERS and replace it by VG_DEEPEST_BACKTRACE. For sure, removing limitation 1 is good : users are less limited, and unless someone really wants a suppression of more than 25 entries, this does not change the behaviour. Removing limitation 2 means that users using --num-callers > 25 and --gen-suppressions=yes will now generate bigger suppression entries. IMO, that is a consistent/understandable behaviour , but as this is a (small) behaviour difference with 3.11, better ask for feedback before commit :). So, any objection/feedback ? Thanks Philippe NB: of course, all existing suppression entries/files still work as before. |
|
From: Mark W. <mj...@re...> - 2016-08-26 11:40:42
|
Hi Philippe, On Fri, 2016-08-26 at 13:14 +0200, Philippe Waroquiers wrote: > For sure, removing limitation 1 is good : users are less limited, > and unless someone really wants a suppression of more than 25 entries, > this does not change the behaviour. > > Removing limitation 2 means that users using --num-callers > 25 > and --gen-suppressions=yes will now generate bigger suppression > entries. > > IMO, that is a consistent/understandable behaviour , but as this is a > (small) behaviour difference with 3.11, better ask for feedback before > commit :). > > So, any objection/feedback ? I cannot imagine (maybe I am not trying too hard?) that anybody would rely on --gen-suppressions=yes being limited to just 25 entries by default. So such a change seems fine to me. Thanks, Mark |