On 2006-4-24 23:58 UTC, Erik Baluba wrote:
> Greg, thanks for your valuable tips.
> This is getting a bit off topic but regarding mpatrol. I've now spent some
> time reading the manual, powerful stuff. However it seems rather outdated,
> the last version is from 2002? Also, the traffic on the mpatrol mailing list
> over at Yahoo is almost extremely low.
It really does seem that the author has moved on to other things.
Yet it's an excellent piece of work, and very well documented,
and I've found nothing as good for the msw platform that's free.
(Somewhere in this mailing list's archives is a comparative
survey I wrote a few years ago). And malloc() is malloc(), after
all--it hasn't changed a lot since 2002; however, libstdc++ and
gcc have changed, and no one ever seems to have figured out an
ideal way of using mpatrol with dlls.
I've had particular difficulty using mpatrol with wxWidgets
and gcc versions later than gcc-3.2.3 . One or two people I
work with are digging into this; we believe it's not a problem
with wxWidgets, because reverting to gcc-3.2.3 helps immensely,
but so far we aren't sure what the real problem is. We've tried
or running with this in the environment:
but this is going to take more research.
However, for my console-mode standalone programs, mpatrol seems
to work fine, even with the latest MinGW gcc, IIRC. And where it
works, it works very well indeed: more than once, it's found
errors in my code that saved me hours of painful debugging.
> Since I didn't succeed compiling it myself I found a binary distribution of
> mpatrol on the mingw site and tried to use it. I have problems using it with
> STL. If I include mpatrol.h before the stl includes I get compiler errors
> about redefintions of "delete" etc. If I move the include after the STL
> includes everything compiles fine but the linker then fails on duplicated
> symbols, obviously :-)
I built it myself, using
It's possible that the precompiled binary at mingw.org uses an
older version of gcc that's incompatible with what you're using,
I suppose. I've never included "mpatrol.h"; it's not that I have
any reason to think that wouldn't work, it's just that I've never
tried it or found a need to.
> Is there a way to use mpatrol only for your own code, I mean to exclude it
> from intercepting the STL stuff? I'm really not that interested in getting
> stats from the stl containers, since I expect that the memory corruption
> doesn't occure there.
I suspect (but do not definitely know) that, by default, libstdc++'s
pool allocator has the effect of making the C++ standard library
mostly invisible to mpatrol (unless you use something like
GLIBCXX_FORCE_NEW). I suspect that this gives a few spurious errors
if you set up mpatrol to look for leaks.
Our current strategy is to use the debug version of libstdc++ to
find errors in the way we use the standard library, and also to
use mpatrol to find other problems. I hope we can evolve this
into a robust general strategy; probably mudflap
will play some role eventually.
Of course, if you have a GNU/Linux system, there are some good tools
there. And there may be some non-free tools that would help on the
msw platform; I wouldn't know much about them.
> Also, did you compile mpatrol yourself? I tried to run configure;make under
> the pkg/auto directory but the compile fails miserably.
I've heard that from others, too. For now, I use the altered
makefile cited above. Maybe we'll find a way to fix the
autotools build for MinGW as part of our ongoing research.