general mudflap question

[Eyal Lebedinsky <eyal at eyal dot emu dot id dot au>]

Now that I am starting to follow up on violation  reports, I still
find myself unable to reconcile the information in the log with
the source code. It is probably time for me to understand better
the capabilities of the mudflap system.

I am now tracking a report that seems to come and go as I add
debug printing. It also moves about as I change the value of
-crumple-zone. This feels very much like a classic stack
overwrite and I am trying to understand how effective mudflap
is expected to be in detecting this.

If every pointer is checked then is it not the case that this
should not happen? OK, where can a breach take place?
	- in external code (libc etc.)
	- where else?

Naturally, at this point I am running non-threaded programs
only. And I should make it clear that so far more of the reports
are confirmed as problems in my code rather than misreports
my mudflap.

So, in short, I am asking:
	What is the scope of mudflap? What is the limit of
	its ability to detect violations?


And for some light entertainment I will now offer a specific
question that should demonstrate the limits of my current
understanding of the situation...

First the report:
=================
*******
mudflap violation 1 (check/read): time=1049877825.828932 ptr=09a4dfe8
size=8 pc=409c4086 location=`queue.c:421 (skqupt)'
      /home/eyal/a3mfn/bin/libssaiok.so(skqupt+0x1a0) [0x409c4086]
{queue.c:421}
      /home/eyal/a3mfn/bin/libssaiok.so [0x40a63d83] {sort.c:1443}
      /home/eyal/a3mfn/bin/libssaiok.so(skx094+0x4f3b) [0x40a7fb13]
{sort.c:2183}
      /home/eyal/a3mfn/bin/libssan3tb.so [0x4020742e] {Could not resolve
symbol}
      /home/eyal/a3mfn/bin/libssan3tb.so(n3gn21+0xbb0) [0x40209fb9]
{geneln.c:3322}
      /home/eyal/a3mfn/bin/testbed [0x80b50e2] {ssalm.c:2665}
      /home/eyal/a3mfn/bin/testbed [0x80d12df] {ssalm.c:4246}
      /home/eyal/a3mfn/bin/testbed [0x80dda46] {ssalm.c:4797}
      /home/eyal/a3mfn/bin/testbed(salmdt+0xd83) [0x80e0004]
{ssalm.c:4971}
      /home/eyal/a3mfn/bin/testbed [0x8061ad3] {testbed.c:3516}
      /home/eyal/a3mfn/bin/testbed [0x8065e95] {testbed.c:4105}
      /home/eyal/a3mfn/bin/libssaiok.so(skmain+0xecf) [0x409aff08]
{main.c:1041}
      /home/eyal/a3mfn/bin/testbed(main+0x4e9) [0x8064309]
{testbed.c:3850}
      /lib/libc.so.6(__libc_start_main+0xa4) [0x40b74914] {no debugging
symbols found)...(gdb}
      /home/eyal/a3mfn/bin/testbed(free+0x31) [0x804ab81] {Could not
resolve symbol}
Nearby object 1: checked region begins 0B into and ends 7B into
mudflap object 096d0788: name=`malloc region'
bounds=[09a4dfe8,09a4e04f] size=104 area=heap check=1r/0w liveness=1
watching=0
alloc time=1049877825.826980 pc=40b48f42

Looking up the code I see these snippets:
=========================================

struct ssa_queue {
        long            n;
        long            flags;
        ...
};
...

skqupt()
{
	struct ssa_queue	*q;
	...
421:	if (!(SSA_QUEUE_NO_LOCKING & q->flags) &&
422:		SSARC_BAD (rc = ssa_mutex_lock (q->mutex))) {


[the proliferation os 'ssa' in the code is related to the company
name and not to tree-ssa, which is just a happy coincidence]

Here I see that a violation is discovered in accessing 'q->flags'. I
verified it by adding this line just before line 421

	if (0 == q->flags)
		rc = 1;

and surely an identical report was generated. While I am rather sure
that
the item in question was initialised (my problem to track it) my actual
question is about the 'size=8' in the first line. The memory area in use
here is 4 bytes long (actually confirmed), so what gives?

TIA

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