[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Jun 2013 10:31:40 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems
On Sun, Jun 16, 2013 at 12:43:08PM +0200, Jens Gustedt wrote:
> Am Sonntag, den 16.06.2013, 11:18 +0100 schrieb Justin Cormack:
> > On Sun, Jun 16, 2013 at 10:31 AM, Jens Gustedt <jens.gustedt@...ia.fr> wrote:
> > > BTW, I used valgrind to help me finding such stuff on initialization,
> > > but the tons of false positives that musl triggers because of the str
> > > functions and calloc are really a pain.
> >
> > It would be nice to ship a valgrind suppressions file shipped with
> > Musl to ignore these, I have always found it very helpful to have as a
> > part of the documentation in order to not worry about trying to work
> > out myself which are false positives when working with a project. You
> > can use valgrind --gen-suppressions to produce them, but I guess we
> > need to check that they are not in fact bugs!
> >
> > (The valgrind maintainers are also very responsive to issues)
>
> yes, I know about that possibility and already used this in the
> past. What would bother me more is that by switching of the check for
> strlen, e.g., valgrind wouldn't find real user code errors when I pass
> an uninitialized char[] to it. Switching off all the checks for the
> str*** functions would somehow be counter productive in the context of
> valgrind.
Is there no way to make the suppression more fine-grained? For
example, "ignore up to wordsize-1 sequential invalid reads in this
function" would give the desired behavior. glibc has some sort of
suppression for these functions; what does valgrind do for glibc?
> Also for calloc I am not sure that when we switch off the false
> positive (where musl assumes a certain gcc behavior for what in
> general is UB)
musl is not assuming any gcc behavior. It's assuming its own
implementation of malloc, which is valid because calloc is part of the
malloc implementation. From an implementation-internal standpoint,
musl's malloc does not just return a pointer to an object of size n.
It returns a pointer to offset 2*sizeof(size_t) in an object of size
2*sizeof(size_t)+n which is possibly (depending on the bits in the
extra header) a subobject of a much larger object.
> valgrind would still capture the fact that the malloced
> object is 0 initialized. If it doesn't we would get even more false
> positives.
I wish we could find a good way around this. Unfortunately the obvious
solution (accessing malloc via an alias) would break since we have two
different malloc implementations that can be used in static linking,
and I don't see any way to make the alias bind to the one that's
actually going to be used.
Is there any fancier sort of suppression we could do?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
