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

[Eyal Lebedinsky]

"Frank Ch. Eigler" wrote:
> 
> Hi -
> 
> On Sun, Apr 06, 2003 at 01:32:53PM +1000, Eyal Lebedinsky wrote:
> > [...]
> > Good, I now wrapped ctime() and shmat() with __mf_[un]register()
> > calls and this removed the reports.
> 
> (Patch please?)

Well, the patch is to my code (I already had a ctime wrapper and
now added a __mf_[un]register pair). I do not see how it can be done
as a proper mf runtime as I register the memory with a size known only
to me (the shmat case). But maybe I can inquire the shared memory
system for the size instead? I will check.

BTW, is there a way to ask mudflap to figure the size by itself? I
can then register the ctime result (or strerror etc.) and let mf
runtime do a strlen without triggering an error yet. Maybe
something as simple as this for registering an initialised string:

void
__mf_register_str (void *ptr, int type, const char *name)
{
	__mf_register (ptr, strlen (ptr), type, name);
}

And maybe checking 'ptr' first?

> > BTW, for such foreign objects,
> > how do I set the size when it is unknown (e.g. for 'ctime' I now
> > cheat and say '64'), and what type do I use (I use GUESS)?
> 
> For ctime, the size is probably 26 or 27, and the type should
> be STATIC.  For other functions, it varies case by case.

STATIC? I understand that in a multithreaded situation the ctime area
is allocated per-thread, and may be releases on thread exit, or even
on the next call from the same thread. I think that the correct type
depends on the libc implementation.

> > And just to be sure I did not miss a post, the getmem/usemem example
> > does show a real problem, right? [...]
> 
> It shows a real problem in your test program.  You're allocating a piece
> of memory with malloc(), so it is uninitialized.  Its contents are
> undefined, but you're reading from it.  The libmudflap default option
> "-check-initialization" is designed to detect exactly this.  Had you
> used calloc(), or wrote to the buffer first, there would be no
> violation shown.  (This is a pretty naive algorithm - nowhere near
> what valgrind does.)

OK, I did not realise mudflap generates uninited errors. Where can I
find a list of the mudflap errors and their meaning then? I will check
to see if this is what happens in my real program.

> > [...] here is an example report which I find very hard to use:
> > [...]/libmudflap.so.0(__mfwrap_memcmp+0x13c) [0x40b39bac]
> >       /ssa/builds/20030404n/bin/libssaiok.so [0x40a85d51]
> >       /ssa/builds/20030404n/bin/libssaiok.so [0x40a84c93]
> 
> Yeah.  Unfortunately libmudflap and glibc don't use debugging
> data to get more precise locations.  I expect we could use an
> external "addr2line" child process to map raw PC values to
> source:line coordinates.  Care to try writing up such an option
> for libmudflap, perhaps based on libjava/gnu/gcj/runtime/NameFinder.java?
> (I believe there used to be a C/C++ version of that little function too.)

I now have a perl script that reads the error log and parses the hex
values into file:line (was written by a workmate, uses gdb). It will
be posted soon.

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>