• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 304
  • Last Modified:

Memory leaks in the C runtime library

I've tried to compile with VC++ under Unicode, defining UNICODE and created a simple wWinMain() function, and defined my entry point correctly. The program compiles and runs, but I get memory leaks reported by NuMega BoundsChecker from the two standard files in the C runtime library - stdargv.c and stdanvp.c, even if all I do is just return from the WinMain (i.e. there is no code in WinMain. ) The memory leaks are quite bad, totalling about 6K. Any ideas why this is?
Please post your replies to TomP@Rebellion.co.uk.
1 Solution
Are you using MFC then?

Did you make wWinMainCRTStartup() the entrypoint procedure in the project settings (link tab, ouput category)?
Tom_PAuthor Commented:
No, I am using straight Windows. And yes, I did specify the entry point correctly (in fact i think that the program wouldn't link otherwise. )
Any ideas would be very appreciated.
Does the problem occur in the release build or only the debug build?  The debug C++ runtime uses a different set of memory functions, and these may contain leaks.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tom_PAuthor Commented:
I worked it out last night.
The problem is the following:
If (and only if) building a non-MFC application for Windows do the following:

1) #define UNICODE //not _UNICODE
2) specify WinMain as your main function (not wWinMain)
3) leave the compiler entry point set to normal (not       wWinMainCRTSStartup)

On my machine with VC++ 6.0 SP4 this builds a unicode program (i.e. all functions called are the <fnname>W's as
opposed to <fnname>A's, e.g. MessageBoxW gets called correctly, not MessageBoxA )

Thanks for your help.
P.S. Is there any way I could give the points to myself?
>> give the points to myself?
No, but you can delete the question and they will be refunded.

What you've done is create a progrma that calls unicode functions, but has an ASCII entry point.  Is that what you wanted?
Tom_PAuthor Commented:
Well not quite neitod, but it doesn't leak memory. Can you think of any reason why having an ascii entry point would cause trouble?
I am really getting tired of this. Have a look at the following piece of code:
int APIENTRY WinMain( /*params here*/)
 return 0;
Tom_PAuthor Commented:
When comiled under ANSI, no problems.
If I define _UNICODE, the versions of all the fns. called will actually be the char * versions. Which leads me to believe that _UNICODE is MFC specific.

When I define UNICODE, all fns. are wide character ones.
If I change WinMain to wWinMain and Entry point to wWinMainCRTStartup, compiles and links fine, BUT! there is a 6k memory leak in the runtime library.
When I use WinMain and normal entry point, no problems.
This is really annoying me now.
Anyway, I'd be gratefull for any ideas on this from anyone.
I use MSCV++ 6.0 with SP4, and the tool that reports memory leaks is BoundsChecker version 6.5.
Thanks, Tom
>> Can you think of any reason why having an ascii entry
>> point would cause trouble?
No, but I'm only vaguely aquanted with the VC start-up code.  I've stepped through it a few times and looked at parts in detail, but I'm not thrououghly familiar with it.

>> _UNICODE is MFC specific.
yes, moistly it controls what libraries an MFC program links to and then in AFXv_w32.h it defines the vlaue of UNICODE which is the value used by windows.h.

You might try stepping through the startup-code and see where it gets lost.  Most likely it is something to do with translating the parameters to wide haracter

I wouldn't loose too much sleep over this.  (Well, actually I probably would, but I'm too compulsive too.)  This is not goin to be a steady memory leak.  i.e. it won't continue to consume memory during the program life and eventually cause a crash.  In fact, it you get it fixed, it probably won't change anything.  Most likely the memory will not be deleted until the program returns from the entry point anyways.  So it getting it delted at the program end, rather than never deleted, is not really of much value.   But I hate loose ends myself....
Tom_PAuthor Commented:
That is what I am thinking, I know (I hope) as soon as the code finishes the memory leak will be cleaned up by windows, but - I like to know what's going on. On the other hand, I have been assuming all the way that BoundChecker got it right... maybe there is a problem elsewhere..?
Anyway, thanks for all your input.
>> I know (I hope) as soon as the code finishes the memory leak will be cleaned
When the program ends, the memory is returned to the OS.  There is no doubt about that.  
I think you forgot this question. I will ask Community Support to close it unless you finalize it within 7 days. Unless there is objection or further activity,  I will suggest to refund the points and PAQ at zero points since you found your own answer.

The link to the Community Support area is: http://www.experts-exchange.com/jsp/qList.jsp?ta=commspt

Points reduced to 0 and placed in PAQ

Thank you
E-E Moderator
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now