|
From: Philippe W. <phi...@sk...> - 2012-07-23 20:48:17
|
On Mon, 2012-07-23 at 14:29 +0200, Petar Jovanovic wrote: > Sure, I do not mind. This is the approach in which we live with it. > > Petar > > On Mon, Jul 23, 2012 at 2:14 PM, John Reiser <jr...@bi...> wrote: > > The complaint from memcheck identifies an actual error (*not* a false positive) > > that is present in the code. The user should update to the fixed glibc > > as soon as possible. In the meantime, the user should not trust any process > > which receives a [Linux kernel] signal. > > > > Do not suppress the complaint. Yes, the situation is bad; but it would be > > even worse to hide on purpose the correct diagnosis of an actual error > > which may well cause silent, random, incorrect output. Will it really be a random silent incorrect output ? I understand that it will either rather work (if not at the last mapped stack page) or else will fail with SEGV. It will be difficult for most users to see that the error reported by Valgrind is not caused by their own code. So, if this particular error can be suppressed precisely, it looks preferable to me (but no strong opinion about that). >From looking at the default.supp, it looks like the preferred approach is to suppress the errors in glibc and other such libs (X, libX11, ...) even if it is not clear that it is a false positive. So, if the suppression rule is called something like: suppress-a-real-bug-in-mips-glibc see http://....... then a user which uses -v will see something more understandable (IMO). Philippe |