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

[Eyal Lebedinsky <eyal@eyal.emu.id.au>]

"Frank Ch. Eigler" wrote:
> 
> 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.

Good, I now wrapped ctime() and shmat() with __mf_[un]register()
calls and this removed the reports. 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)?

And just to be sure I did not miss a post, the getmem/usemem example
does show a real problem, right? It is this one that gets me mostly,
filling up my logs (it trips a few times per record in a sort
program).

> 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.

So, the "location=`zz.c:19 (usemem)'" is from compile time, but the
following traceback is from glibc runtime? I never saw line numbers
in this trace, only hex offsets, and I do use '-g'. Can I make it
show line numbers (am I missing an option)? Just to indicate what
gives me this trouble, here is an example report which I find very
hard to use:

*******
mudflap violation 2 (check/read): time=1049594102.444443 ptr=415aba22
size=2 pc=
40b39bac location=`(memcmp 1st arg)'
      /usr/local/gcc-mudflap/lib/libmudflap.so.0(__mfwrap_memcmp+0x13c)
[0x40b39
bac]
      /ssa/builds/20030404n/bin/libssaiok.so [0x40a85d51]
      /ssa/builds/20030404n/bin/libssaiok.so [0x40a84c93]
Nearby object 1: checked region begins 444922B into and ends 444923B
into
mudflap object 083ab778: name=`malloc region'
Nearby object 2: checked region begins 444922B into and ends 444923B
into
mudflap object 08398d20: name=`malloc region'

My libssaiok.so is very large, and use extensively, and I do not see
how I can relate the report context to my sources.

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