|
From: Patrick O. <pat...@in...> - 2007-03-05 08:03:55
|
On Sat, 2007-03-03 at 16:48 +0100, lemmel wrote: > Hi, > I'm a desperate house developper : I can't get the suppression of some errors. > > Look at the following step : > > I run valgrind in order to find potential problem : > $ valgrind --suppressions=./common_QT_X.supp --gen-suppressions=yes bin/laseqi1 > > then I have the classical : > ==9972== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- > I ask the print suppression and I have : [...] > and I "cat" this suppression text into a file : test > I hit the "c" key and quit the application. Then I re-run valgrind : > > $ valgrind --suppressions=./test --suppressions=./common_QT_X.supp --gen-suppressions=yes bin/laseqi1 > > and then : > ==10100== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- [...] > > the same error. Are you sure the error is not suppressed? If I remember correctly, the last time I worked on suppressions I noticed that with --gen-suppressions=all valgrind suppressed the error report and then printed a suppression although the error was already suppressed. I'm not sure whether that is intentional. It was easy enough to deal with: only suppressions generated after an error report are really new. If there is a chance to not print redundant suppressions, that's what I would prefer, though. Along the same line is the situation where exactly the same problem is triggered multiple times. Only on the first occasion should the suppression be copied; this has to be detected manually. Perhaps valgrind could make life easier for users by a) not printing suppressions for suppressed problems and b) automatically add a printed suppression to the current run so that future occurrences do not print another redundant suppression? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |