lmi
[Top][All Lists]
Advanced

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

Re[2]: [lmi] malloc-debugger problems


From: Vadim Zeitlin
Subject: Re[2]: [lmi] malloc-debugger problems
Date: Sun, 8 Jan 2006 14:07:35 +0100

On Sun, 08 Jan 2006 07:57:12 +0000 Greg Chicares <address@hidden> wrote:

GC> Let me refine my suggestion. I think a class's ctor(s) and dtor need
GC> to reside on the same side of a dll boundary.

 I didn't know such a requirement exist and I'm still sceptical that it
really does as I don't see any logical explanation for this. What I do know
beyond any doubt is that all memory should be allocated and freed using the
same instance of the CRT. There are 2 ways to ensure this:

1. always allocate/free memory in the same module (i.e. always in the main
   EXE or always in the DLL)
2. use a single copy of CRT in the entire program

Your proposal above would ensure (1) in this particular case of wxString
but it's probably not the only one. My suggestion would be to use instead
CRT as DLL, i.e. do (2).

GC> Please see item (4) in my 04 Dec 2005 19:13:55 +0000 message. It cites
GC> an article in an ms newsgroup that suggests that this is a problem not
GC> only for gcc.

 If you mean this message

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

then it just says exactly the same as I said above: using different CRTs is
going to result in problems.

GC> More important, it links to this documented test case
GC> 
GC>   http://savannah.nongnu.org/download/lmi/mpatrol-dll-test-20030509.tgz
GC> 
GC> that demonstrates the problem.

 I didn't have time to really test it yet (should I take time to do it?)
but I think that there are only 2 cases when this will work:

1. fully static linking: everything linked statically, mpatrol linked to
   the main executable only
2. fully dynamic linking: everything, i.e. wx and CRT and mpatrol linked
   dynamically, wx DLL must be linked with mpatrol as well

Anything else has no chance of working. These two should work but (2)
one might not if there is a bug in mpatrol. (1) should definitely work but
is impractical.

GC> The sole purpose of that archive is to demonstrate, through a
GC> stripped-down, minimal testcase, the problem with wxString that seems
GC> to underlie all these mpatrol difficulties.

 Sorry, I still don't believe that wxString is special in any way
whatsoever. I'm sure there are other classes in wxWidgets which allocate
memory in their ctors and free it in their dtors. So I think it would be
much better to find the correct build settings which ensure that mpatrol
always works instead of trying to tweak the code. Even if we can make it
work now, this solution would be very fragile and could be easily broken
later.

 Regards.
VZ





reply via email to

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