Re: [lmi] malloc-debugger problems

[Greg Chicares]

On 2006-1-8 13:07 UTC, Vadim Zeitlin wrote:
> 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.

If the weaker condition you propose is sufficient to make this work correctly,
then that's more than okay with me.

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

Isn't (2) the default with MinGW? It always links 'libmsvcrt.a':

  C:/tmp[0]$/MinGW-20050827/bin/g++ -dumpspecs |grep msvc
  %{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

and 'objdump -p' shows a dependency on 'msvcrt.dll':

  C:/tmp[0]$/MinGW-20050827/bin/objdump -p /opt/lmi/bin/lmi_wx_shared.exe |grep 
'DLL Name'
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: msvcrt.dll
        DLL Name: USER32.dll
        DLL Name: wxmsw254d_gcc_custom.dll
        DLL Name: wx_new.dll
        DLL Name: liblmi.dll

It's listed twice, but the first occurrence has only low-level file I/O
functions.

Does this mean (2) has been achieved? Otherwise, how can it be achieved?

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

Okay. Still, I don't see how I could have mixed different CRTs.

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

If you can take a look at that archive's README, it reports results on
eight different cases. Its case 4, I think, is your case 2, although
I'm not sure about the CRT issue as discussed above.

> (1) should definitely work but
> is impractical.

I had dismissed that as impractical. OTOH, if it works reliably, then
perhaps it's the best solution. Can you think of any way that a static
build could have a memory-allocation problem that's not present in a
dynamic build of the same sources? That seems "obviously" impossible
to me, but clearly there's more to this than I understand, and I'd
like to know what you think.

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

Yes, finding a build method that works robustly is certainly best.