mudflap problem, and a decode script

[Frank Ch. Eigler]

Hi -


On Tue, Apr 15, 2003 at 09:31:43PM +1000, Eyal Lebedinsky wrote:
> [...]
> Below is the report. You will notice that we have a
> violation at 0x083c4fb0. This memory region was
> malloced, then freed, then malloced again at the
> same place. Notice that the earlier allocation
> (object 2) has a check=0r/2w while the current
> has check=1r/0w. Is it possible that a write to
> this region was credited to the wrong object?

I don't think so.

It seems that the initialization checking code is doing
more harm than good at this stage.  We need more wrapper
functions to properly tag buffers written-to by system
libraries.  I'll commit a patch shortly to disable this
check by default.  I advise you to continue testing only
with the MUDFLAP_OPTIONS="-no-check-initialization".


> I am questioning how reliable I should consider mudflap
> (after all it is under active development). 

Given that this exact same problem has come up three or
four times now, you might disable this particular check
and go on using mudflap.  More instances of the same
known problem do not help assess its reliability.


> I would have looked at the code deeper if I had some
> doco to go by, I hope to learn more as I go.

I sent you a draft of the mudflap paper, discussing
both internals and usage - what more would you like to
see in the documentation?


> [...] As an aside, a workmate developed this simple script
> to decode the mudflap reports hex -> file:line. This
> is driving gdb which does the actual work. [...]

Thanks for the sample.  I'd likely prefer a less-sophisticated
lighter-weight application of addr2line, right within libmudflap.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20030415/5bec65e0/attachment.sig>