Re: mudflap: how do I give size for 'void *' objects? - example

["Frank Ch. Eigler" <fche@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]

Hi -

On Sat, Apr 05, 2003 at 04:26:41PM +1000, Eyal Lebedinsky wrote:
> > I have a problem where I get a large number of reported violations
> > when accessing objects acquired through something like
> >         p = shmat()
> > where the size of the object is unknown (unless mudflap uses
> > extra internal knowledge).

In general, libmudflap does not have suitable wrapper functions
already, the application may manually register/unregister
objects using functions declared in mf-runtime.h.

shmat() wrapping will be a bit tricky, because the size of the
newly mapped memory region is not present as a local parameter
of the call.  libmudflap will probably need to intercept shmget()
too just to get this information.

> Here is a simple program that demonstrates the problem with ctime().
> Note how the fprintf() works OK (no violation) but the strlen()
> fails. I assume that mudflap has its own strlen() wrapper that
> trips on the "foreign" pointer returned from ctime().

Right.  Enabling libmudflap heuristics (e.g. "-heur-proc-map") should
cases like this work, if one does not want to write more wrappers.

It would be nice to think of a way of getting such data pointers out of
libraries.  Or compile them in such a way that they are able to register
their individual static variables (but without necessarily the full
mudflap internal checking).


You also wrote:

> And while I am on the ebox, why do I not see a proper stack trace
> with line numbers? What I got for this test is below. The
>         'zz.c:19 (usemem)'
> is correct, but I would have liked to see (and expected)
>         'zz.c:48 (main)'

You're not looking at a stack trace.  These strings are not extracted
from the debugging information, but is rather constructed at compile-time
into literal strings from the trees, to identify the check site or
variable.  To parse the quoted error message:

> mudflap violation 1 (check/read): time=1049530365.371258 ptr=08051f30
> size=1 pc=080487f9 location=`zz.c:19 (usemem)

-> The usemem function at zz.c:19 made a one-byte memory read of the
given address.


>       ./zz(__mf_check+0x245) [0x80487f9]
>       ./zz(main+0x52) [0x8048876]
>       /lib/libc.so.6(__libc_start_main+0xbb) [0x4005714f]

-> The stack traceback, as supplied by glibc, went thusly.  Since usemem
doesn't show up, maybe it was inlined here, or maybe glibc doesn't show
it in the traceback for another reason.


> Nearby object 1: checked region begins 0B into and ends 0B into
> mudflap object 08051f60: name=`malloc region'
> bounds=[08051f30,08051f34] size=5 area=heap check=1r/0w liveness=1
> watching=0

-> This is the first read to a heap region.  It hasn't been written
to, as far as libmudflap knows ("0w"), and it was not registered as
initialized ("area=heap"), so the initialization checking code
detected a violation.  If you just want to shut this check up,
you can use MUDFLAP_OPTIONS="-no-check-initialization", though it
would be better to find out why libmudflap thinks that the buffer
hasn't been written to already.


> alloc time=1049530365.371099 pc=40019f32
>       /usr/local/gcc-mudflap/lib/libmudflap.so.0(__real_malloc+0x142)
> [0x40019f32]
>       ./zz(__mf_check+0xfc) [0x80486b0]
>       ./zz(main+0x25) [0x8048849]
> number of nearby objects: 1

-> This is the glibc stack traceback at the moment of allocation.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]