Re: mudflap problem

[fche at redhat dot com (Frank Ch. Eigler)]

"Doug Graham" <dgraham@nortelnetworks.com> writes:

> [...]  I'm fairly sure that mudflap doesn't check any pointer arith

That's correct - mudflap does not check pointer manipulation, except
the final dereference.

> so I thought that there would be plenty of cases similar
> (but not quite the same) to the one that he is asking about that would not
> be caught by mudflap.  But then I tried this:
> [...]
> I thought that since b+16 points to the base of a, mudflap would not
> complain about the dereference in foo().  But it did somehow know that
> the pointer passed in to foo() was derived from 'b' rather than 'a'.

I believe this is an optimization artifact.  With "-O2", the declaration of
"a" is marked somehow as unused (it is), and libmudflap does not get
a startup-time registration call for it.  Thus b[16] is checked and is found
to refer to an invalid address.

You may find running programs with
  env MUDFLAP_OPTIONS="-trace-calls" <your-program>
will clarify the actual behavior of the code.

> How did mudflap know in foo(), without using fat pointers, that the
> pointer was derived from 'b'?  

It didn't.

> Herman's bounds-checking patches can catch this as well, but they do
> so by adding some pad bytes between 'a' and 'b', so that b+16 does
> not point to anything that can be legally dereferenced.

Adding some padding between static objects would help mudflap catch
such off-by-one (but not off-by-many) accesses in the same way.


> [...]  My original intent was to suggest that maybe mudflap could
> (perhaps optionally) check pointer arithmetic as well [...]

It might help catch more problems earlier and with more specificity,
but this would require a lot more instrumentation code to be
run, and thus slow down execution even more.


- FChE