Re: [lmi] malloc-debugger problems

[Greg Chicares]

At last I have time to resume this discussion--sorry for the delay.

On 2005-12-12 12:06 UTC, Vadim Zeitlin wrote:
> On Sun, 04 Dec 2005 19:13:55 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Open 'skeleton.exe' and close it immediately: the msvc rtl reports
> GC> 
> GC> | Runtime Error!
> GC> |
> GC> | Program: C:\opt\skeleton\bin\skeleton.exe
> GC> |
> GC> | This application has requested the Runtime to terminate it in an 
> unusual way.
> GC> | Please contact the application's support team for more information.
> 
>  This looks like a CRT mismatch, doesn't it?

To me, it looks like C++'s std::terminate() (or C's abort()) was called.
Try this demonstration:

  C:/tmp[0]$cat terminate.cpp
  #include <exception>
  int main() {std::terminate();}
  C:/tmp[0]$/MinGW-20050120/bin/g++ terminate.cpp -mwindows
  C:/tmp[0]$./a

That produces exactly the same message quoted above.

Many things could cause std::terminate() to be called; C++98 18.6.3.3/1
says it's called whenever exception handling must be abandoned, for
instance.

I don't see any way a CRT mismatch could arise here, if you mean two
different versions of the CRT. I'm using only MinGW tools, which always
use the same CRT. I suspect the problem is two distinct instances of
the same CRT--one on the dll side, and the other on the app side--which
is perhaps the sort of CRT mismatch you had in mind.

> GC>   c. Try addressing the problem by changing wx.
> GC> 
> GC> I don't know whether this would work, but it's worth a try. It may
> GC> not be easy. And we don't really know whether wx is the cause of
> GC> the problem: it might be the compiler. To rule that out, I tried
> GC> building wx-2.5.1 with MinGW gcc-3.4.2, but got many occurrences
> GC> of this error:
> GC> 
> GC>   ../../include/wx/msw/private.h:342: error: `cbSize' undeclared (first 
> use this function)
> 
>  This was fixed in later releases, basically you just need to replace
> cbSize with this->cbSize (as cbSize is a dependent name).

Thanks. I also found it necessary to apply these two sets of changes:
  
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/rawbmp.h.diff?r1=1.18&r2=1.19
  
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/rawbmp.h.diff?r1=1.21&r2=1.22

I made a new copy of my (patched) wx-2.5.1 sources and built this way,
in a new ms "command prompt" session:

  C:\Documents and 
Settings\chicares>Path=C:\WINNT\system32;C:\WINNT;C:\MinGW-20050827\bin
  C:\Documents and Settings\chicares>cd \wxWindows-2.5.1x\build\msw
  C:\wxWindows-2.5.1x\build\msw>\usr\bin\make --keep-going -f makefile.gcc 
SHARED=1 MONOLITHIC=1 CXXFLAGS="-DNO_GCC_PRAGMA -ggdb" >buildlog-20060107 2>&1

  C:\wxWindows-2.5.1x\build\msw>cd ..\..\contrib\build\xrc
  C:\wxWindows-2.5.1x\contrib\build\xrc>\usr\bin\make --keep-going -f 
makefile.gcc SHARED=1 MONOLITHIC=1 CXXFLAGS="-DNO_GCC_PRAGMA -ggdb" 
>buildlog-20060107 2>&1

Copying the resulting dlls to the directory to which I installed a
fresh build of the 'skeleton' branch, I ran it, hit Esc to get out
of the 'About' dialog, then did only File | Exit, which produced:

  ---------------------------
  Microsoft Visual C++ Runtime Library
  ---------------------------
  Runtime Error!

  Program: C:\opt\skeleton-wx251-gcc342\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 the resulting 'mpatrol.log' contains three errors like this:
  ERROR: [NOTALL]: free: 0x103A0F08 has not been allocated
and also this one:
  ERROR: [ILLMEM]: illegal memory write at address 0x5F647261

This seems very similar to the symptoms detailed in item (5) of my
message of 04 Dec 2005 19:13:55 +0000. All the 'mpatrol.log' stack
traces involve one of these functions:
  wxString::operator=(wxString const&)
  wxString::~wxString()
  wxString::wxString()

> GC> Perhaps writing all wx destructors out of line would solve the
> GC> problem, but that's just speculation; yet that probably ought to
> GC> be done anyway. A good place to start might be the wxString classes,
> GC> because they seem to be implicated in the mpatrol error messages
> GC> reported above.
> 
>  I don't understand why having wxString dtor inline should be a problem
> though? And if you build with wxUSE_STL=1 you'd be using std::basic_string
> whose dtor is probably inline anyhow (and we can't change this).

Let me refine my suggestion. I think a class's ctor(s) and dtor need
to reside on the same side of a dll boundary. Implementing them all
out of line is just the easiest way to guarantee that, but maybe there
are other ways. Please see item (4) in my 04 Dec 2005 19:13:55 +0000
message. It cites an article in an ms newsgroup that suggests that
this is a problem not only for gcc. More important, it links to this
documented test case

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

that demonstrates the problem. That archive's 'dllclass.hpp' has
  class sg      corresponding to wxString
  class sg_base corresponding to wxStringBase
These are simplified versions of the wx classes, as evidenced by the
lock() and unlock() members, with reference counting. The sole purpose
of that archive is to demonstrate, through a stripped-down, minimal
testcase, the problem with wxString that seems to underlie all these
mpatrol difficulties.