lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] malloc-debugger problems


From: Vadim Zeitlin
Subject: Re: [lmi] malloc-debugger problems
Date: Mon, 12 Dec 2005 13:06:30 +0100

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?

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).

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).

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]