Discussion:
memory leaks (again)
(too old to reply)
Lt Col Gecko Pointdexter
2005-03-30 11:56:53 UTC
Permalink
Hi all,

I experience the following problem with VS 2003 (Visual C++):

- I have a solution containing several dll projects and one executable
- When running the Debug build, with the debugger attached (F5), I get
very many leaks reported
- I managed to identify where the reported allocation takes place, and
I am positive that memory is freed; I know for sure because
- One of the leaks (all of the ones I tested - there are too many to
test all) is reported in the constructor of a static object, and the
respective pointer is deallocated in the destructor.
- I put a breakpoint in the destructor and now when I run I get the
following problem
- Memory is allocated, I see my gui
- I close the application
- I get a bunch of leaks reported in the output window
- After the memory leak dump is complete, the debugger breaks in the
destructor and execution continues and memory is deallocated.

So, what I am trying to say is that the debugger reports the leaks
before the execution is actually over, and after the leaks are
reported, the static objects are destructed, freeing the memory which
was reported as leaked. This confuses me as I have troubles seeing if
there are any real memory leaks. I hope I made myself clear.

Has anyone had this problem or does anybody know of a remedy?

TIA,
Gec.
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Stoyan Damov
2005-03-30 14:32:17 UTC
Permalink
The code you're going to see sucks, but at least it might help you:

#include <memory.h>
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>

// this is your problem
struct leak
{
void* p_;
leak()
{
p_ = malloc(1000);
}
~leak()
{
// this is called, but _CrtDump... reports a false positive, right?
free(p_);
// this is essential for being able to call ~leak() again later
p_ = 0;
}
} g_leak;

// this is the workaround
#ifndef NDEBUG
void destroy_static_objects()
{
g_leak.~leak();
}
#endif // NDEBUG

int main(int /* argc */, char* /* argv */ [])
{
atexit((void(__cdecl*)(void))_CrtDumpMemoryLeaks);
// chaining destroy_static_objects after _CrtDumpMemoryLeaks is essential
#ifndef NDEBUG
atexit(destroy_static_objects);
#endif // NDEBUG
return 0;
}

The destructors of your static objects will be called twice, but you
shouldn't have a problem making them safe for multiple executions.

Hope that helps,
Stoyan



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bill Arnette
2005-03-30 15:11:14 UTC
Permalink
Can you allocate your static object on the stack instead? If so, then wrap
it in its own scope inside the scope of the CrtDmp call

i.e.

int main()
{
// Initialize CRT debugging


{
CMyStaticObject o;

// other stuff

}

// o is now destroyed and all its memory has been released

CrtDmpLeaks(); // or whatever its called
}


This way you are certain the destructor is called before the dump report
-----Original Message-----
Sent: Wednesday, March 30, 2005 6:57 AM
Subject: [OT] memory leaks (again)
Hi all,
- I have a solution containing several dll projects and one executable
- When running the Debug build, with the debugger attached (F5), I get
very many leaks reported
- I managed to identify where the reported allocation takes place, and
I am positive that memory is freed; I know for sure because
- One of the leaks (all of the ones I tested - there are too many to
test all) is reported in the constructor of a static object, and the
respective pointer is deallocated in the destructor.
- I put a breakpoint in the destructor and now when I run I get the
following problem
- Memory is allocated, I see my gui
- I close the application
- I get a bunch of leaks reported in the output window
- After the memory leak dump is complete, the debugger breaks in the
destructor and execution continues and memory is deallocated.
So, what I am trying to say is that the debugger reports the leaks
before the execution is actually over, and after the leaks are
reported, the static objects are destructed, freeing the memory which
was reported as leaked. This confuses me as I have troubles seeing if
there are any real memory leaks. I hope I made myself clear.
Has anyone had this problem or does anybody know of a remedy?
TIA,
Gec.
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Lt Col Gecko Pointdexter
2005-03-30 15:39:11 UTC
Permalink
Hi guys thanks for replies, unfortunatelly none of the options
provided is an option :(, if I had just one static leaking maybe it
would have been OK to use Stoyan's approach, but it is a rather large
project and practically every singleton is "leaking"... allocating on
the stack is also not an option, by design :(

This wasn't happening before - it all started when references to MFC
were removed from the DLLs I was talking about in the first mail - it
is likely that there is a connection...

Any other ideas?
Post by Bill Arnette
Can you allocate your static object on the stack instead? If so, then wrap
it in its own scope inside the scope of the CrtDmp call
i.e.
int main()
{
// Initialize CRT debugging
{
CMyStaticObject o;
// other stuff
}
// o is now destroyed and all its memory has been released
CrtDmpLeaks(); // or whatever its called
}
This way you are certain the destructor is called before the dump report
-----Original Message-----
Sent: Wednesday, March 30, 2005 6:57 AM
Subject: [OT] memory leaks (again)
Hi all,
- I have a solution containing several dll projects and one executable
- When running the Debug build, with the debugger attached (F5), I get
very many leaks reported
- I managed to identify where the reported allocation takes place, and
I am positive that memory is freed; I know for sure because
- One of the leaks (all of the ones I tested - there are too many to
test all) is reported in the constructor of a static object, and the
respective pointer is deallocated in the destructor.
- I put a breakpoint in the destructor and now when I run I get the
following problem
- Memory is allocated, I see my gui
- I close the application
- I get a bunch of leaks reported in the output window
- After the memory leak dump is complete, the debugger breaks in the
destructor and execution continues and memory is deallocated.
So, what I am trying to say is that the debugger reports the leaks
before the execution is actually over, and after the leaks are
reported, the static objects are destructed, freeing the memory which
was reported as leaked. This confuses me as I have troubles seeing if
there are any real memory leaks. I hope I made myself clear.
Has anyone had this problem or does anybody know of a remedy?
TIA,
Gec.
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Stoyan Damov
2005-03-30 15:57:33 UTC
Permalink
Does buying BoundsChecker count? ;)

Cheers,
Stoyan

On Wed, 30 Mar 2005 18:39:11 +0300, Lt Col Gecko Pointdexter
Post by Lt Col Gecko Pointdexter
Hi guys thanks for replies, unfortunatelly none of the options
provided is an option :(, if I had just one static leaking maybe it
would have been OK to use Stoyan's approach, but it is a rather large
project and practically every singleton is "leaking"... allocating on
the stack is also not an option, by design :(
This wasn't happening before - it all started when references to MFC
were removed from the DLLs I was talking about in the first mail - it
is likely that there is a connection...
Any other ideas?
Post by Bill Arnette
Can you allocate your static object on the stack instead? If so, then wrap
it in its own scope inside the scope of the CrtDmp call
i.e.
int main()
{
// Initialize CRT debugging
{
CMyStaticObject o;
// other stuff
}
// o is now destroyed and all its memory has been released
CrtDmpLeaks(); // or whatever its called
}
This way you are certain the destructor is called before the dump report
-----Original Message-----
Sent: Wednesday, March 30, 2005 6:57 AM
Subject: [OT] memory leaks (again)
Hi all,
- I have a solution containing several dll projects and one executable
- When running the Debug build, with the debugger attached (F5), I get
very many leaks reported
- I managed to identify where the reported allocation takes place, and
I am positive that memory is freed; I know for sure because
- One of the leaks (all of the ones I tested - there are too many to
test all) is reported in the constructor of a static object, and the
respective pointer is deallocated in the destructor.
- I put a breakpoint in the destructor and now when I run I get the
following problem
- Memory is allocated, I see my gui
- I close the application
- I get a bunch of leaks reported in the output window
- After the memory leak dump is complete, the debugger breaks in the
destructor and execution continues and memory is deallocated.
So, what I am trying to say is that the debugger reports the leaks
before the execution is actually over, and after the leaks are
reported, the static objects are destructed, freeing the memory which
was reported as leaked. This confuses me as I have troubles seeing if
there are any real memory leaks. I hope I made myself clear.
Has anyone had this problem or does anybody know of a remedy?
TIA,
Gec.
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
--
Cheers,

Stoyan



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Stoyan Damov
2005-03-30 15:44:43 UTC
Permalink
I guess he can't. Otherwise he'll have to pass a reference/pointer to
CMyStaticObject everywhere he needs it. He's probably using the class
as a singleton.

Cheers,
Stoyan
Post by Bill Arnette
Can you allocate your static object on the stack instead? If so, then wrap
it in its own scope inside the scope of the CrtDmp call
i.e.
int main()
{
// Initialize CRT debugging
{
CMyStaticObject o;
// other stuff
}
// o is now destroyed and all its memory has been released
CrtDmpLeaks(); // or whatever its called
}
This way you are certain the destructor is called before the dump report
-----Original Message-----
Sent: Wednesday, March 30, 2005 6:57 AM
Subject: [OT] memory leaks (again)
Hi all,
- I have a solution containing several dll projects and one executable
- When running the Debug build, with the debugger attached (F5), I get
very many leaks reported
- I managed to identify where the reported allocation takes place, and
I am positive that memory is freed; I know for sure because
- One of the leaks (all of the ones I tested - there are too many to
test all) is reported in the constructor of a static object, and the
respective pointer is deallocated in the destructor.
- I put a breakpoint in the destructor and now when I run I get the
following problem
- Memory is allocated, I see my gui
- I close the application
- I get a bunch of leaks reported in the output window
- After the memory leak dump is complete, the debugger breaks in the
destructor and execution continues and memory is deallocated.
So, what I am trying to say is that the debugger reports the leaks
before the execution is actually over, and after the leaks are
reported, the static objects are destructed, freeing the memory which
was reported as leaked. This confuses me as I have troubles seeing if
there are any real memory leaks. I hope I made myself clear.
Has anyone had this problem or does anybody know of a remedy?
TIA,
Gec.
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
Yahoo! Groups Links
--
Cheers,

Stoyan



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
j***@public.gmane.org
2005-03-30 15:51:23 UTC
Permalink
Does your .exe use MFC? If it doesn't that would explain why you would
get the false positives. Basically, MFC calls _crtdumpmemory when MFC is
unloaded. This functions reports all memory allocated by the (C-Runtime)
CRT as being "leaked". MFC will get unloaded when the last MFC dll gets
unloaded. This is a problem, because the scope of the CRT is longer than
the scope of MFC.

But, if your .exe is using MFC, then MFC won't get unloaded until right
before the process exits (and there won't be any outstanding allocated
memory)...

There are other reasons why MFC memory leak detection would run
prematurely, before everything has been unloaded. We were bit with this
situation, which sounds very similar to yours. This KB article describes
it: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q167929&

Basically, the problem occurs when you are running multiple debug
versions of MFC in the same process. The fix is to make sure that all of
your libraries use the same version (including UNICODE vs. non-UNICODE)

I would recommend that you try making your .exe an MFC application using
MFC as a shared dll. Then, make sure that are not loading more than one
version of a debug MFC dll...

Caveat: These are just my impressions. I may have gotten something
wrong...

Regards,
Johan




-----Original Message-----
From: Lt Col Gecko Pointdexter [mailto:vebcaster-***@public.gmane.org]
Sent: Wednesday, March 30, 2005 7:39 AM
To: win_tech_off_topic-***@public.gmane.org
Subject: Re: [OT] memory leaks (again)


Hi guys thanks for replies, unfortunatelly none of the options provided
is an option :(, if I had just one static leaking maybe it would have
been OK to use Stoyan's approach, but it is a rather large project and
practically every singleton is "leaking"... allocating on the stack is
also not an option, by design :(

This wasn't happening before - it all started when references to MFC
were removed from the DLLs I was talking about in the first mail - it is
likely that there is a connection...

Any other ideas?
Post by Bill Arnette
Can you allocate your static object on the stack instead? If so, then
wrap it in its own scope inside the scope of the CrtDmp call
i.e.
int main()
{
// Initialize CRT debugging
{
CMyStaticObject o;
// other stuff
}
// o is now destroyed and all its memory has been released
CrtDmpLeaks(); // or whatever its called }
This way you are certain the destructor is called before the dump
report
-----Original Message-----
Sent: Wednesday, March 30, 2005 6:57 AM
Subject: [OT] memory leaks (again)
Hi all,
- I have a solution containing several dll projects and one
executable
- When running the Debug build, with the debugger attached (F5), I
get very many leaks reported
- I managed to identify where the reported allocation takes place,
and I am positive that memory is freed; I know for sure because
- One of the leaks (all of the ones I tested - there are too many to
test all) is reported in the constructor of a static object, and the
respective pointer is deallocated in the destructor.
- I put a breakpoint in the destructor and now when I run I get the
following problem
- Memory is allocated, I see my gui
- I close the application
- I get a bunch of leaks reported in the output window
- After the memory leak dump is complete, the debugger breaks in the
destructor and execution continues and memory is deallocated.
So, what I am trying to say is that the debugger reports the leaks
before the execution is actually over, and after the leaks are
reported, the static objects are destructed, freeing the memory
which was reported as leaked. This confuses me as I have troubles
seeing if there are any real memory leaks. I hope I made myself
clear.
Post by Bill Arnette
Has anyone had this problem or does anybody know of a remedy?
TIA,
Gec.
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links










Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bill Arnette
2005-03-30 16:52:02 UTC
Permalink
Maybe the Singleton Destroyer pattern can help?

http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Scott Kell
2005-03-30 17:24:22 UTC
Permalink
Hi,

I'd like to take the User's Manual for our product, which is written in Word
and includes hyperlinks to bookmarks defined in the manual, and convert it
to a PDF, preserving the hyperlinks; and do the conversion from a build
script.

Thus, only the "source" .DOC document is kept under source control, and the
build script can generate the PDF as opposed to keeping both the DOC and PDF
file under source control.

In the past I've used CutePDF Writer along with MS Word's automation
features to print the document to the CutePDF Writer "printer" - but that
doesn't preserve the hyperlinks in the document.

I've looked at the Acrobat SDK
(http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/intro_to_sdk/
UserGuide.pdf) and it's not clear at all as to how to do what I want to do.

And googling this topic, it appears that it's a Frequently Asked Question
but with no really good answer.

Any ideas?

Thanks!
Scott




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Craig Andera
2005-03-30 19:43:47 UTC
Permalink
Post by Scott Kell
I'd like to take the User's Manual for our product, which is
written in Word and includes hyperlinks to bookmarks defined
in the manual, and convert it to a PDF, preserving the
hyperlinks; and do the conversion from a build script.
There's at least one other PDF printer driver on SourceForge that may or may
not do what you want.






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
John Elliot
2005-03-30 20:10:15 UTC
Permalink
Post by Scott Kell
I'd like to take the User's Manual for our product, which is written in Word
and includes hyperlinks to bookmarks defined in the manual, and convert it
to a PDF, preserving the hyperlinks; and do the conversion from a build
script.
Keywords: ghostscript, redmon. Available here [1].

There's probably something better, but ghostscript works, and it's free.
It can be a little painful to get it configured though. This [2] will help.

I guess you'd use Office automation to do the printing. I'd probably use
javascript to work with the COM stuff.

John.

[1] http://www.cs.wisc.edu/~ghost/
[2] http://www.cs.wisc.edu/~ghost/redmon/en/redmon.htm



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
John Elliot
2005-03-30 20:16:12 UTC
Permalink
Post by John Elliot
Post by Scott Kell
I'd like to take the User's Manual for our product, which is written in Word
and includes hyperlinks to bookmarks defined in the manual, and convert it
to a PDF, preserving the hyperlinks; and do the conversion from a build
script.
Keywords: ghostscript, redmon. Available here [1].
Ah.. RTFQ.

I'm not sure what will happen to hyperlinks when you pump it through the
printer. Maybe acrobat will pick them up, maybe it won't..

I've been using iTextSharp [1], a .NET port of iText [2], for creating
PDFs recently. You *could* do that, but I doubt you'd want to.

John.

[1] http://itextsharp.sourceforge.net/
[2] http://www.lowagie.com/iText/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Scott Kell
2005-03-30 20:45:52 UTC
Permalink
Yes, it's been my experience that the printer driver based PDF creators do
not preserve hyperlinks - why would an application even think to preserve
hyperlink / bookmark information when sending a document to a print device?

I haven't tried redmon, but I've tried ps2pdf; that process doesn't preserve
hyperlink / bookmark info.

iTextSharp looks cool - doesn't fit what I need now but I'll have to keep an
eye on it.

Reading up on it, it sounds as if the key are things called pdfmarks - these
are PostScript extensions which allow for bookmarks, links, annotations, and
"optional content". So a simple PDF creator based on a printer driver would
have to tell the calling application (like MS Word) to pass bookmark /
hyperlink info to the printer driver so it can insert these pdfmarks into
the resulting file. I have a hunch that there's no facility to allow for
that to happen though.

Thanks!
Scott

-----Original Message-----
From: John Elliot [mailto:jj5-KpA1RCgkr+***@public.gmane.org]
Sent: Wednesday, March 30, 2005 3:16 PM
To: win_tech_off_topic-***@public.gmane.org
Subject: Re: [OT] PDF creation from NAnt
Post by John Elliot
Post by Scott Kell
I'd like to take the User's Manual for our product, which is written in Word
and includes hyperlinks to bookmarks defined in the manual, and convert it
to a PDF, preserving the hyperlinks; and do the conversion from a build
script.
Keywords: ghostscript, redmon. Available here [1].
Ah.. RTFQ.

I'm not sure what will happen to hyperlinks when you pump it through the
printer. Maybe acrobat will pick them up, maybe it won't..

I've been using iTextSharp [1], a .NET port of iText [2], for creating
PDFs recently. You *could* do that, but I doubt you'd want to.

John.

[1] http://itextsharp.sourceforge.net/
[2] http://www.lowagie.com/iText/



Yahoo! Groups Links










Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Lt Col Gecko Pointdexter
2005-03-31 07:13:04 UTC
Permalink
Hi all, thanks again for replies.

I have a solution with several dll's (none uses MFC) and an exe (uses
MFC). I doubt it is using different versions of MFC inside the single
executable, plus VS2003 (which I use) is not listed in the "impacted
products" on MSDN page.

The singleton destroyer does not help in this case, I am using a
pattern similar to the one described by Scott in the article posted by
Bill, so no luck.

Buying BoundsChecked :) is not an option at the moment either

Regards,
Gec
Post by Bill Arnette
Maybe the Singleton Destroyer pattern can help?
http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
j***@public.gmane.org
2005-03-31 15:06:39 UTC
Permalink
First of all the situation does exist in VS2003, since it is a side
effect of how MFC was (and still is) designed. Basically, when either
mfc71d.dll or mfc71ud.dll is unloaded, it calls _CrtDumpMemoryLeaks().

You want to make sure that this DLL is unloaded after all of your dlls
(that use the dll version of the CRT) are unloaded.

There are two ways that you will link to your dlls.

If you link to a dll implicitly, the order that the dlls are loaded is
the order of the .lib's found in the "Input:Additional Dependencies"
area of the VS project property page. The order for unloading is the
opposite of this order. You are likely loading MFC as a "default"
library. The "default" libraries are loaded after all the explicitly
specified libraries are loaded.

So that hints to your fix. In your .exe properties, place mfc71.lib or
mfc71ud.lib before your libs in the "Input:Aditional Dependencies". Then
these dlls won't get loaded as "defualt" libraries anymore. And since
they are loaded first, they will get unloaded last, which means that the
_CrtDumpMemoryLeaks() won't run until after all your dlls get unloaded.

If you are explicitly loading your dll(ie: using LoadLibrary), then it
will get unloaded automatically before all the implicitly loading dlls.
So, explicitly loaded dlls should not be causing you any problems.

Another reason, as I said before, is running more than one debug version
of the mfc dlls in the same process. You should look for the following
modules in your process (mfc42d.dll, mfc42ud.dll, mfc71d.dll,
mfc71ud.dll, mfc70d.dll, mfc70ud.dll). There should be only one of
these...

To debug these problems, and see where the dump memory leaks gets hit,
you can put a breakpoint in dbgheap.c at _CrtDumpMemoryLeaks...

Regards,
Johan



-----Original Message-----
From: Lt Col Gecko Pointdexter [mailto:vebcaster-***@public.gmane.org]
Sent: Wednesday, March 30, 2005 11:13 PM
To: win_tech_off_topic-***@public.gmane.org
Subject: Re: [OT] memory leaks (again)


Hi all, thanks again for replies.

I have a solution with several dll's (none uses MFC) and an exe (uses
MFC). I doubt it is using different versions of MFC inside the single
executable, plus VS2003 (which I use) is not listed in the "impacted
products" on MSDN page.

The singleton destroyer does not help in this case, I am using a pattern
similar to the one described by Scott in the article posted by Bill, so
no luck.

Buying BoundsChecked :) is not an option at the moment either

Regards,
Gec
Post by Bill Arnette
Maybe the Singleton Destroyer pattern can help?
http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links










Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Lt Col Gecko Pointdexter
2005-03-31 15:44:37 UTC
Permalink
I don't set anything in the Input:Additional dependencies - I use
project dependencies to tell the compiler which project dependes on
which. In headers, I have __declspec(dllexport) or
__declspec(dllimport) as needed.

I don't know how to force the order of loading the dlls in this case.

Gecko
Post by j***@public.gmane.org
First of all the situation does exist in VS2003, since it is a side
effect of how MFC was (and still is) designed. Basically, when either
mfc71d.dll or mfc71ud.dll is unloaded, it calls _CrtDumpMemoryLeaks().
You want to make sure that this DLL is unloaded after all of your dlls
(that use the dll version of the CRT) are unloaded.
There are two ways that you will link to your dlls.
If you link to a dll implicitly, the order that the dlls are loaded is
the order of the .lib's found in the "Input:Additional Dependencies"
area of the VS project property page. The order for unloading is the
opposite of this order. You are likely loading MFC as a "default"
library. The "default" libraries are loaded after all the explicitly
specified libraries are loaded.
So that hints to your fix. In your .exe properties, place mfc71.lib or
mfc71ud.lib before your libs in the "Input:Aditional Dependencies". Then
these dlls won't get loaded as "defualt" libraries anymore. And since
they are loaded first, they will get unloaded last, which means that the
_CrtDumpMemoryLeaks() won't run until after all your dlls get unloaded.
If you are explicitly loading your dll(ie: using LoadLibrary), then it
will get unloaded automatically before all the implicitly loading dlls.
So, explicitly loaded dlls should not be causing you any problems.
Another reason, as I said before, is running more than one debug version
of the mfc dlls in the same process. You should look for the following
modules in your process (mfc42d.dll, mfc42ud.dll, mfc71d.dll,
mfc71ud.dll, mfc70d.dll, mfc70ud.dll). There should be only one of
these...
To debug these problems, and see where the dump memory leaks gets hit,
you can put a breakpoint in dbgheap.c at _CrtDumpMemoryLeaks...
Regards,
Johan
-----Original Message-----
Sent: Wednesday, March 30, 2005 11:13 PM
Subject: Re: [OT] memory leaks (again)
Hi all, thanks again for replies.
I have a solution with several dll's (none uses MFC) and an exe (uses
MFC). I doubt it is using different versions of MFC inside the single
executable, plus VS2003 (which I use) is not listed in the "impacted
products" on MSDN page.
The singleton destroyer does not help in this case, I am using a pattern
similar to the one described by Scott in the article posted by Bill, so
no luck.
Buying BoundsChecked :) is not an option at the moment either
Regards,
Gec
Post by Bill Arnette
Maybe the Singleton Destroyer pattern can help?
http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist
Yahoo! Groups Links
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
j***@public.gmane.org
2005-03-31 15:12:12 UTC
Permalink
s/mfc71.lib/mfc71d.lib

-----Original Message-----
From: johan_ericsson-+***@public.gmane.org [mailto:johan_ericsson-+***@public.gmane.org]
Sent: Thursday, March 31, 2005 7:07 AM
To: win_tech_off_topic-***@public.gmane.org
Subject: RE: [OT] memory leaks (again)


First of all the situation does exist in VS2003, since it is a side
effect of how MFC was (and still is) designed. Basically, when either
mfc71d.dll or mfc71ud.dll is unloaded, it calls _CrtDumpMemoryLeaks().

You want to make sure that this DLL is unloaded after all of your dlls
(that use the dll version of the CRT) are unloaded.

There are two ways that you will link to your dlls.

If you link to a dll implicitly, the order that the dlls are loaded is
the order of the .lib's found in the "Input:Additional Dependencies"
area of the VS project property page. The order for unloading is the
opposite of this order. You are likely loading MFC as a "default"
library. The "default" libraries are loaded after all the explicitly
specified libraries are loaded.

So that hints to your fix. In your .exe properties, place mfc71.lib or
mfc71ud.lib before your libs in the "Input:Aditional Dependencies". Then
these dlls won't get loaded as "defualt" libraries anymore. And since
they are loaded first, they will get unloaded last, which means that the
_CrtDumpMemoryLeaks() won't run until after all your dlls get unloaded.

If you are explicitly loading your dll(ie: using LoadLibrary), then it
will get unloaded automatically before all the implicitly loading dlls.
So, explicitly loaded dlls should not be causing you any problems.

Another reason, as I said before, is running more than one debug version
of the mfc dlls in the same process. You should look for the following
modules in your process (mfc42d.dll, mfc42ud.dll, mfc71d.dll,
mfc71ud.dll, mfc70d.dll, mfc70ud.dll). There should be only one of
these...

To debug these problems, and see where the dump memory leaks gets hit,
you can put a breakpoint in dbgheap.c at _CrtDumpMemoryLeaks...

Regards,
Johan



-----Original Message-----
From: Lt Col Gecko Pointdexter [mailto:vebcaster-***@public.gmane.org]
Sent: Wednesday, March 30, 2005 11:13 PM
To: win_tech_off_topic-***@public.gmane.org
Subject: Re: [OT] memory leaks (again)


Hi all, thanks again for replies.

I have a solution with several dll's (none uses MFC) and an exe (uses
MFC). I doubt it is using different versions of MFC inside the single
executable, plus VS2003 (which I use) is not listed in the "impacted
products" on MSDN page.

The singleton destroyer does not help in this case, I am using a pattern
similar to the one described by Scott in the article posted by Bill, so
no luck.

Buying BoundsChecked :) is not an option at the moment either

Regards,
Gec
Post by Bill Arnette
Maybe the Singleton Destroyer pattern can help?
http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt
Yahoo! Groups Links
--
You're going to reap just what you sow.
Lt. Col. Gecko Pointdexter - expert specialist



Yahoo! Groups Links










Yahoo! Groups Links










Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/win_tech_off_topic/

<*> To unsubscribe from this group, send an email to:
win_tech_off_topic-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Continue reading on narkive:
Loading...