[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] malloc-debugger problems
From: |
Greg Chicares |
Subject: |
Re: [lmi] malloc-debugger problems |
Date: |
Mon, 09 Jan 2006 06:11:17 +0000 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
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.