[lmi] malloc-debugger problems

[Greg Chicares]

Synopsis: We need a malloc debugger because it saves a very great deal
of debugging effort, letting us spend more time on development. The only
reasonable choice for msw seems to be mpatrol, which worked with older
toolsets, but no longer works with the compiler or wx library we use in
production. Yet both those tools are out of date and need to be upgraded.

Overview:

1. What's a malloc debugger?

2. Why use one?

3. Why choose mpatrol?

4. mpatrol was made to work with older toolsets

5. mpatrol doesn't work with newer toolsets

6. What's the best solution for newer toolsets?

In detail:

1. What's a malloc debugger?

  http://www.cbmamiga.demon.co.uk/mpatrol/
| The mpatrol library is a powerful debugging tool that attempts to
| diagnose run-time errors that are caused by the wrong use of
| dynamically allocated memory.

2. Why use one?

  http://valgrind.org/info/
| automatically detect many memory management [...] bugs, avoiding
| hours of frustrating bug-hunting, making your programs more stable

3. Why choose mpatrol?

It's the best choice for msw:

  http://article.gmane.org/gmane.comp.gnu.mingw.user/4829

and it works on other platforms, too, even though valgrind is
probably best for GNU/Linux.

4. mpatrol was made to work with older toolsets

See this discussion:

  http://lists.wxwidgets.org/archive/wx-dev/msg33061.html
  http://lists.wxwidgets.org/archive/wx-dev/msg34246.html

and the extensive documentation in this archive's 'README':

  http://savannah.nongnu.org/download/lmi/mpatrol-dll-test-20030509.tgz

in particular with respect to wxString's inline dtor.

Here's another explanation of the problem with inline dtors:

  
http://groups.google.com/group/microsoft.public.vc.debugger/msg/c457b936ca9496f4

Here's a workaround:

  http://savannah.nongnu.org/cgi-bin/viewcvs/lmi/lmi/wx_new.hpp

that helps prevent the inline-dtor with wxString etc.

Here's a patch for another problem observed with wx:

  
http://sourceforge.net/tracker/index.php?func=detail&aid=1112376&group_id=19456&atid=319456

and a unit test for it:

  http://savannah.nongnu.org/cgi-bin/viewcvs/lmi/lmi/mpatrol_patch_test.cpp

With yesterday's 20051204T0157Z cvs commits to the skeleton branch,
mpatrol once again works, with gcc-3.2.3 (MinGW 20030915 release)
and wx-2.5.1 only.

5. mpatrol doesn't work with newer toolsets

Non-GUI unit tests work fine with mpatrol, using gcc-3.4.2 . The
problem is GUI code.

Again using the skeleton branch as of 20051204T0157Z, as in the
preceding list item, problems occur with gcc-3.4.2 (MinGW 20050120)
and wx-2.5.4 (and, of course, with wx and mpatrol obligatorily
rebuilt with the same compiler).

Open 'skeleton.exe' and close it immediately: the msvc rtl reports

| Runtime Error!
|
| Program: C:\opt\skeleton\bin\skeleton.exe
|
| This application has requested the Runtime to terminate it in an unusual way.
| Please contact the application's support team for more information.

and 'mpatrol.log' says:

| total warnings:    0
| total errors:      3

The errors all seem to involve wxString: demangling the internal
names that mpatrol reports yields

  C:/MinGW-20050120/bin[0]$./c++filt _ZN8wxStringaSERKS_
  wxString::operator=(wxString const&)

  C:/MinGW-20050120/bin[0]$./c++filt _ZN8wxStringD1Ev
  wxString::~wxString()

  C:/MinGW-20050120/bin[0]$./c++filt _ZN8wxStringC1Ev
  wxString::wxString()

Running the GUI unit tests (Test | Unit test) results in an
'mpatrol.log' that's over a megabyte, instead of 3K as for a clean
run; it reports 429 errors.

These problems are not prevented by the techniques described here:
  http://www.valgrind.org/docs/manual/faq.html#faq.reports
viz.,
  export GLIBCXX_FORCE_NEW=1; ./skeleton
  export GLIBCPP_FORCE_NEW=1; ./skeleton
or, alternatively,
  build with "CPPFLAGS='-D__USE_MALLOC'"

6. What's the best solution for newer toolsets?

  a. Go bare--just don't use a malloc debugger.

Not acceptable. I've spent multiple days tracking down a single
memory-allocation error in production that could have been found
immediately in development with mpatrol. We've already gone too
long (since 2005-01) without a malloc debugger, at too great a cost.

  b. Use a different malloc debugger.

I don't know of any free alternative to mpatrol that works under msw;
Vadim
  http://lists.wxwidgets.org/archive/wx-dev/msg34246.html
had suggested dmalloc, but
  http://article.gmane.org/gmane.comp.gnu.mingw.user/4829
it seemed very unpromising for msw three years ago. And I hesitate to
trade one tool's known set of problems for another's unknowns.

  c. Try addressing the problem by changing wx.

I don't know whether this would work, but it's worth a try. It may
not be easy. And we don't really know whether wx is the cause of
the problem: it might be the compiler. To rule that out, I tried
building wx-2.5.1 with MinGW gcc-3.4.2, but got many occurrences
of this error:

  ../../include/wx/msw/private.h:342: error: `cbSize' undeclared (first use 
this function)

Perhaps writing all wx destructors out of line would solve the
problem, but that's just speculation; yet that probably ought to
be done anyway. A good place to start might be the wxString classes,
because they seem to be implicated in the mpatrol error messages
reported above. Apparently some work was done along these line years
ago:

  http://lists.wxwidgets.org/archive/wx-dev/msg34246.html
|
| This has been fixed by Gilles

but cvs HEAD:

  
http://cvs.wxwidgets.org/viewcvs.cgi/*checkout*/wxWidgets/include/wx/string.h?rev=1.210

still shows five inline dtors.

  d. Find more workarounds like lmi's 'wx_new.?pp'.

I don't think this would be easy. IIRC, 'wx_new.?pp' prevented memory
leaks, not memory-allocation errors, and it certainly didn't prevent
segfaults--but now we have errors and a segfault--so it might be
altogether futile.

At any rate, other efforts to resolve wx issues in lmi code have
turned out to be bad ideas--for example, lmi's 'wx_workarounds.hpp',
which
  http://lists.gnu.org/archive/html/lmi/2005-08/msg00002.html
turned out to conflict with a different solution to the same problem
that was applied to a later version of wx; or, for another example,
the 'Window'-menu problem
  http://lists.gnu.org/archive/html/lmi/2005-12/msg00007.html
that mysteriously unmanifests itself when a previously-necessary lmi
workaround is reverted.

  e. Revert to gcc-3.2.3 and wx-2.5.1 .

Reverting the compiler is silly. Reverting wx is impracticable:
the new product editor will need the latest version; and it's
already too painful to be using even wx-2.5.4 . So this is the
worst solution except for every other one available today.