I’d like someone to explain how to ‘decrypt’ the following mudflap output:
mudflap violation 1 (check/write): time=1352235104.713060 ptr=0x61a000 size=20
pc=0x2b12e5f4 location=`connect.c:645:3 (connect_init)'
[0x613d88]
Nearby object 1: checked region begins 252B after and ends 271B after
mudflap object 0x619f30: name=`malloc region'
bounds=[0x619f00,0x619f04] size=5 area=heap check=0r/0w liveness=0
alloc time=1352235104.712374 pc=0x2b12db34 thread=715976208
/lib/libmudflapth.so.0(__mf_register+0x80) [0x2b12db34]
Nearby object 2: checked region begins 23121B after and ends 23140B after
mudflap dead object 0x6145d8: name=`calloc region'
bounds=[0x614550,0x6145af] size=96 area=heap-init check=0r/0w liveness=0
alloc time=1352235104.704859 pc=0x2b12db34 thread=715976208
/lib/libmudflapth.so.0(__mf_register+0x80) [0x2b12db34]
dealloc time=1352235104.711583 pc=0x2b12d498 thread=715976208
number of nearby objects: 2
Could someone walk me through this line-by-line? This doesn’t make much sense at the moment :-/ …
Thanks in advance!
The first lines give you the most important data:
I would look into your source
connect.cat line 645 in functionconnect_init. This is where the access violation happens. This need not be the offending code, but it is a good start to look around for bad code. If this function is clean, try to assess which code is callingconnect_initand where the pointer or heap region comes from.The other parts seem to identify some heap objects (malloc region, calloc region). The first one still in use (alloc time only) and the second one already given back to heap (alloc and dealloc time).