REALLY early memory leaks
Scott E. Johnson
I am using MS VC++ 4.0, and getting a series of 11 memory memory
leaks. Based on the memory allocation numbers, I have determined that
the leaks are being created immediately BEFORE any code in the
constructor of my application object executes. Does anyone have any
idea, how this can be? What can I possibly be doing wrong before
application construction?
--Scott Johnson
Cecil A. Galbraith
Without seeing code, it's hard to tell.
Cecil
--
Cecil Galbraith
CustomSoft mail to cgal...@concentric.net
Free programmer's utilities and MFC tips at
http://www.concentric.net/~cgalbrai
Charles Steinhardt
I would think if you apply the VC 4.2 upgrade opatch this may go away.
Is it consistent with even AppWizard generated code?
Charles Steinhardt[MVP]
Joseph M. O'Leary
It could be some global objects (or static class members) somewhere doing
dynamic memory allocation in their constructors. How exactly were you able
to determine that the memory leaks happen before your code executes,
anyway?
Joe O'
Cecil A. Galbraith <cgal...@concentric.net> wrote in article
<34109B...@concentric.net>...
Joseph M. Newcomer
In an attempt to make MFC "small and fast", Microsoft has compromised
"correctness". Thus, they often don't call destructors on data that
is part of a static initialization or early runtime initialization.
The argument is that "the memory will be freed anyway, so why waste
time and space with appropriate destructor code", but what happens is
that various memory trackers including the debug MFC runtime and
Nu-Mega Bounds Checker detect this failure to release and report a
"spurious" memory leak. While the code is "correct" in the sense that
by the time the destructors would have been called, the process is
about to terminate, it is really annoying to not have everything
properly cleaned up and have to keep sorting the "real" leaks from the
"spurious" leaks.
joe
On Fri, 05 Sep 1997 16:39:20 -0400, "Scott E. Johnson"
<sv...@umich.edu> wrote:
>I am using MS VC++ 4.0, and getting a series of 11 memory memory
>leaks. Based on the memory allocation numbers, I have determined that
>the leaks are being created immediately BEFORE any code in the
>constructor of my application object executes. Does anyone have any
>idea, how this can be? What can I possibly be doing wrong before
>application construction?
> --Scott Johnson
Joseph M. Newcomer
newc...@flounder.com
http://www3.pgh.net/~newcomer
Paul Carter
Scott E. Johnson <sv...@umich.edu> wrote in article
<34106D...@umich.edu>...
>
> I am using MS VC++ 4.0, and getting a series of 11 memory memory
> leaks. Based on the memory allocation numbers, I have determined that
> the leaks are being created immediately BEFORE any code in the
> constructor of my application object executes. Does anyone have any
> idea, how this can be? What can I possibly be doing wrong before
> application construction?
> --Scott Johnson
>
more static variables. You may well be deleting this memory correctly in
the
destructor, but the MSVC memory leak checker runs before the destructors
for static variables are called - resulting in memory leak reports (even
though
they're not really memory leaks)
Paul
--
Reply address has been 'nospammed'.
Joseph M. O'Leary
This is incorrect. All memory allocations performed by the runtime
libraries are explicitly deallocated. When they are not deallocated, you
have a bug, not a Microsoft design decision.
Joe O'
newc...@flounder.com (Joseph M. Newcomer) wrote in article
<34425156....@206.210.64.12>...
> In an attempt to make MFC "small and fast", Microsoft has compromised
> "correctness". Thus, they often don't call destructors on data that
> is part of a static initialization or early runtime initialization.
> The argument is that "the memory will be freed anyway, so why waste
> time and space with appropriate destructor code", but what happens is
> that various memory trackers including the debug MFC runtime and
> Nu-Mega Bounds Checker detect this failure to release and report a
> "spurious" memory leak. While the code is "correct" in the sense that
> by the time the destructors would have been called, the process is
> about to terminate, it is really annoying to not have everything
> properly cleaned up and have to keep sorting the "real" leaks from the
> "spurious" leaks.
> joe
>
> On Fri, 05 Sep 1997 16:39:20 -0400, "Scott E. Johnson"
> <sv...@umich.edu> wrote:
>
> >I am using MS VC++ 4.0, and getting a series of 11 memory memory
> >leaks. Based on the memory allocation numbers, I have determined that
> >the leaks are being created immediately BEFORE any code in the
> >constructor of my application object executes. Does anyone have any
> >idea, how this can be? What can I possibly be doing wrong before
> >application construction?
> > --Scott Johnson
>
Doug Harrison
On Mon, 8 Sep 1997 21:29:21 +0200, "newc...@flounder.com (Joseph M.
Newcomer)" <newc...@flounder.com> wrote:
>In an attempt to make MFC "small and fast", Microsoft has compromised
>"correctness". Thus, they often don't call destructors on data that
>is part of a static initialization or early runtime initialization.
>The argument is that "the memory will be freed anyway, so why waste
>time and space with appropriate destructor code", but what happens is
>that various memory trackers including the debug MFC runtime and
>Nu-Mega Bounds Checker detect this failure to release and report a
>"spurious" memory leak. While the code is "correct" in the sense that
>by the time the destructors would have been called, the process is
>about to terminate, it is really annoying to not have everything
>properly cleaned up and have to keep sorting the "real" leaks from the
>"spurious" leaks.
Besides those insignificant leaks, MFC can report truly spurious leaks
even in DLLs that clean up all their static data, if those DLLs don't
link to the MFC DLL (which BTW *is* the workaround - you just have to
arrange for the debug mode version to link to MFC). I posted a message
on this a while back:
Subject: Spurious memory leak reporting
Date: Thu, 14 Aug 1997 21:28:35 -0500
Message-ID: <u13e0LS...@uppssnewspub04.moswest.msn.net>
Newsgroups: microsoft.public.vc.mfc
The problem seems easily avoidable; in fact, as I described in that
message, MFC appears to go out of its way to create this problem, and
for no gain that I can discern.
Getting back to the problem you're discussing, which involves real,
but insignificant leaks, I find it hard to fault someone who, say,
news an object and never deletes it, if the object is to persist
throughout the program's lifetime and destruction has no necessary
side effects that are being sidestepped. Sometimes, when I shut down a
large program that's been sitting idle for a long time, I listen to my
drives churn for several seconds, and I always wonder if the OS is
paging in a bunch of pointless destruction code and data, the end
result being freeing of memory the OS is going to reclaim anyway. But
I agree, the reporting of these insignificant leaks can really obscure
the significant ones, and unless one can demonstrate the app shutdown
time is a genuine concern, "leaking" memory this way is a poor
trade-off for the developer. I'm just grateful VC5 has vastly speeded
up the IDE output window; VC4 could take minutes to accept the
hundreds of bogus leaks reported, say, after a crash.
(P.S. Sorry if this message (eventually) appears twice; I posted it to
the MS server a couple of days ago, and apparently it wasn't received,
so I'm trying again.)
--
Doug Harrison
dHar...@worldnet.att.net
Dylan NICHOLSON
>> Scott E. Johnson wrote:
>> >
>> > I am using MS VC++ 4.0, and getting a series of 11 memory memory
>> > leaks. Based on the memory allocation numbers, I have determined that
>> > the leaks are being created immediately BEFORE any code in the
>> > constructor of my application object executes. Does anyone have any
>> > idea, how this can be? What can I possibly be doing wrong before
>> > application construction?
>> > --Scott Johnson
>>
memory allocation number...at any rate I think you can do it by setting
a conditional breakpoint inside the CRT source code (something like
dbg_alloc.c, but I can't remember exactly). Then you can look at your
stack trace to find out what it is being constructed.
Dylan
--
--
..yes I *do* know how to write signature files, but I just can't be
bothered really...