Memory leak problems

[Morten Aune Lyrstad]

Ok, now I'm officially confused. I have a large project going, which
uses a win32 ui library I am developing myself. And I'm getting weird
memory leaks. I don't know if I can explain what is going on, but I
really need some help on this one.

Ok, so I have this class defined (written by Randy Charles Morin,
www.kbcafe.com) which detects memory leaks. It creates a memory check
point in the constructor, and another in the destructor, and then
compares the two to find differences. When I want to test for memory
leaks I make a variable with this type at the global level (before
everything else). My thinking is the first-in last-out thing with
constructors and destructors. The first thing to be called would be this
object's constructor, and the last thing would be the destructor. Am I
right?

Ok; so my application Main looks like this:

int __stdcall WinMain(HINSTAN CE hInstance, HINSTANCE hPrevInstance, char
*lpCmdLine, int nCmdShow)
{
CWin32Applicati on *app;
app = MemNew CWin32Applicati on();
int ret = __Win32_RunMain App(app, hInstance, hPrevInstance, lpCmdLine,
nCmdShow);
app->Destroy();
MemDelete app;

return ret;
}

Never mind the weird __Win32_RunMain App, it's really just a temporary
throw-in which collects the command line and runs a Main function in
CWin32Applicati on. I will change this to the better, I swear! :-)

Ok, so the application is allocated, and a function is run which creates
windows, menus, toolbars, controls, documents etc etc etc. Here comes
the weird parts: If I place the control destruction calls in the
destructor of CWin32Applicati on, or in the function "Destroy" as you see
above (app->Destroy()), I get a memory leak. But if I put it in the code
which is called on the win32 message WM_DESTROY, I get NO memory leaks.
What the (insert curse word here) is going on? I'm not really allowed to
put their destruction calls in the WM_DESTROY function, so I can't use
that as a solution. As far as I know, every destruction function for
every control is actually called, I've stepped through the call. Still
memory leaks gets reported.

For the record, I also tried placing the memory leak class variable
within the WinMain itself, but it gave me exactly the same results.

I must admit, I will be very impressed if any of you can help me with
this, but I'm desperate.

Yours,
Morten Aune Lyrstad

[Victor Bazarov]

Re: Memory leak problems

Morten Aune Lyrstad wrote:[color=blue]
> Ok, now I'm officially confused. I have a large project going, which
> uses a win32 ui library I am developing myself. And I'm getting weird
> memory leaks. I don't know if I can explain what is going on, but I
> really need some help on this one.
>
> Ok, so I have this class defined (written by Randy Charles Morin,
> www.kbcafe.com) which detects memory leaks. It creates a memory check
> point in the constructor, and another in the destructor, and then
> compares the two to find differences. When I want to test for memory
> leaks I make a variable with this type at the global level (before
> everything else). My thinking is the first-in last-out thing with
> constructors and destructors. The first thing to be called would be this
> object's constructor, and the last thing would be the destructor. Am I
> right?[/color]

Could be. Or could be not. If other modules have namespace level objects
defined, they may be created before and destroyed after. It has no effect
on memory leak reporting, though.
[color=blue]
> Ok; so my application Main looks like this:
>
> int __stdcall WinMain(HINSTAN CE hInstance, HINSTANCE hPrevInstance, char
> *lpCmdLine, int nCmdShow)
> {
> CWin32Applicati on *app;
> app = MemNew CWin32Applicati on();[/color]

Why not initialise it right away, where you declare it? Never mind... I
suppose 'MemNew' is some kind of a preprocessor wrapper for 'new'.
[color=blue]
> int ret = __Win32_RunMain App(app, hInstance, hPrevInstance,
> lpCmdLine, nCmdShow);
> app->Destroy();
> MemDelete app;[/color]

I bet this is just 'delete app;'.
[color=blue]
>
> return ret;
> }
>
> Never mind the weird __Win32_RunMain App, it's really just a temporary
> throw-in which collects the command line and runs a Main function in
> CWin32Applicati on. I will change this to the better, I swear! :-)[/color]

And drop the double underscores while you're at it. You as a programmer
are prohibited from using double underscores in your names.
[color=blue]
> Ok, so the application is allocated, and a function is run which creates
> windows, menus, toolbars, controls, documents etc etc etc. Here comes
> the weird parts: If I place the control destruction calls in the
> destructor of CWin32Applicati on, or in the function "Destroy" as you see
> above (app->Destroy()), I get a memory leak. But if I put it in the code
> which is called on the win32 message WM_DESTROY, I get NO memory leaks.
> What the (insert curse word here) is going on?[/color]

Well, can you see if your code (regardless of where you put it) does get
called?
[color=blue]
> I'm not really allowed to
> put their destruction calls in the WM_DESTROY function, so I can't use
> that as a solution. As far as I know, every destruction function for
> every control is actually called, I've stepped through the call. Still
> memory leaks gets reported.[/color]

It could simply be a bug in the leak reporting tool you're using.
[color=blue]
> For the record, I also tried placing the memory leak class variable
> within the WinMain itself, but it gave me exactly the same results.[/color]

That's good. It means that the c-tor/d-tor for it work as you thought
they did.
[color=blue]
> I must admit, I will be very impressed if any of you can help me with
> this, but I'm desperate.[/color]

There is probably something OS-specific going on there. The procedures
calls to which you're moving from one place to the other to see that
difference in memory leak reporting are probably behaving differently
_themselves_ if you try to destroy something that has already been removed
by the OS (the WM_DESTROY message probably causes all the windows to close
and your code that frees up some resources may simply short-circuit out of
the deallocation procedures if it sees that there are no windows left).

In any case, it seems like a Windows programming problem, not a C++
language problem, so you're in a wrong newsgroup. As much as some of us
would love to help you, we can't do it here. It would be off-topic.

Try comp.os.ms-windows.program mer.* hierarchy or one of the newsgroups
on msnews.microsof t.com server.

Best of luck!

Victor

[Morten Aune Lyrstad]

Re: Memory leak problems

Well, I've actually been able to solve it, and it was a mixture of
win32api-specific and c++ specific things. Suffice to say, the right
code was being called at the wrong time. Some bad thinking while I was
developing made me connect certain objects to the windows they should
work with, which made it impossible to retrieve them again after the
windows were destroyed. Unfortunately, the fix for this problem
introduced another one, which I will be asking about in a new thread.

Oh, about the underscores thing... I used them so I would be guaranteed
to notice it each time I see them. Stupid solution, fine, but it
works... And I will fix it, once these other more pressing problems are
solved.

I am self-taught (or whatever it is called), so I'm sure I've got a
gazillion bad habits. As long as it's only me who has to live with the
code, it doesn't matter. The problem is, I'm studying to become a
professional programmer, which means that I have to keep a sharp eye out
for such things... so I appreciate your comment about it!

It's too bad that people get so hung up into if it's the right newsgroup
or not. It's hard to determine if such problems are c++-specific,
os-specific or whatever. No offense intended, I'm sure there are
perfectly good reasons for this, but it makes it a bit harder for people
like me to find the right place to ask the questions.

Thank you very much!
Morten Aune Lyrstad

[Stephen Howe]

Re: Memory leak problems

> I am self-taught (or whatever it is called), so I'm sure I've got a[color=blue]
> gazillion bad habits. As long as it's only me who has to live with the
> code, it doesn't matter. The problem is, I'm studying to become a
> professional programmer, which means that I have to keep a sharp eye out
> for such things... so I appreciate your comment about it![/color]

Get hold of all 3 books of Scott Meyers:
Effective C++
More Effective C++
Effective STL

Also Steve Dewhurst's 100 Gotchas

They will knock the bad habits out of you.
And stick around this newsgroup for a while.

Stephen Howe

[KB]

Re: Memory leak problems

Morten Aune Lyrstad wrote:
[color=blue]
> I am self-taught (or whatever it is called), so I'm sure I've got a
> gazillion bad habits. As long as it's only me who has to live with the
> code, it doesn't matter. The problem is, I'm studying to become a
> professional programmer, which means that I have to keep a sharp eye out
> for such things... so I appreciate your comment about it![/color]

Just keep at it. None of this stuff comes overnight.

[color=blue]
>
> It's too bad that people get so hung up into if it's the right newsgroup
> or not. It's hard to determine if such problems are c++-specific,
> os-specific or whatever. No offense intended, I'm sure there are
> perfectly good reasons for this, but it makes it a bit harder for people
> like me to find the right place to ask the questions.[/color]

Just read the FAQ and don't mention "gcc" even if you're stating whether it
possesses a std C++ compliant feature.

KPB