Don,
Microsoft's leak check (at least with MFC) is even more
brain dead than that. No fancy code analysis at all.
It just uses the _CrtMem* heap debug functions. For
it to work, malloc and free must be remapped to malloc_dbg and free_dbg.
The debug versions just stuff the allocated buffer pointer on some list, and pop
it off when the debug free is called. If, when it finally calls
_CrtDumpMemoryLeaks(), there are still objects on the malloc_dbg() list that
haven't been free_dbg()'d... then it reports those as
leaks.
This by itself is pretty useful. The brain dead part
of the MFC implementation is that MFC calls _CrtDumpMemoryLeaks() from an
instance of _AFX_DEBUG_STATE which is globally instanciated. Since there's
apparently no reliable way to make this global instance in the MFC
libs delete after all other globally instanciated classes... it
sometimes (as it does for me with OSG and Producer) get deleted
first.
Since the _AFX_DEBUG_STATE instance is deleted before OSG
and/or Producer's global class instances, it sees all the remaining malloc_dbg()
entries as leaks... even though OSG and Producer are about to free
them.
There's a much better method in the _Crt stuff.
Calling "_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );"
will tell the C runtime to run _CrtDumpMemoryLeaks() when actually exiting the
application... which appears to happen after all the global instances are
cleared. This would correctly report the leaks AFTER OSG/Producer frree
the global class instances. I just haven't taken the time to figure out
how to stop MFC's _AFX_DEBUG_STATE from doing it too. There's some report
hook remapping that might do it, but I haven't quite had the need to dig in to
that stuff quite yet.
One useful feature in the _CrtMem* functions is the ability
to do leak checks at any point in your code, using memory state objects.
You could:
_CrtMemState ms;
_CrtMemCheckpoint(&ms);
some_leaking_function();
_CrtMemDumpAllObjectsSince(&ms);
This will report any new malloc_dbg() objects since the
checkpoint that have not been freed yet. This helps in some cases, when
everything allocated by the code in between is supposed to be deleted.
It's not so useful if you've created objects on some list to be deleted
later. It will see those as leaks too. Well, not really leaks.
Like the name implies... any object allocated that's still around since
the last checkpoint will be reported.
Of course, real mem debug packages do a better job.
But these are useful to know about... since they're already
there.
Darron
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Burns
Sent: Sunday, May 07, 2006 9:54 AM
To: osg users
Subject: Re: [osg-users] First time user - VS7 - horriblememoryleaks?+Producer appears to leak GDI handles on exit
Produder/OSG's use of reference pointer seems to confuse Microsoft's code analyzer, which likely does not track real (or simulated) addresses, but just guesses that when it finds a new with no delete in the code context, it must be a leak.
Ya know, Word, Excell, Powerpoint... these aren't bad applications. Microsoft really should stick to writing applications and leave operating systems and compilers to those who know how.
-don
On 5/6/06, Darron
Black <[EMAIL PROTECTED]>
wrote:
Don,Well, if nobody else seems to have this sort of issue... it very well may just be something about my OpenGL environment. It could be quite difficult to reproduce.I was just hoping the consistency of the 11.2 - 11.5K/sec leak over many different models would give someone insight into letting me know where to look. I commented out all the keyboard/mouse events, and they're not the problem either. The MFC-reported leaks don't seem to grow... (which would cover all the Producer 'new' statements, I think) so those MFC do report are probably all just mis-reported due to the timing of MFC's early reporting and OSG's later freeing.It must be some kind of OpenGL buffers or objects not being freed. ?Anyway... the fame of line entry in a CVS change log isn't all that motivating.. I'll certainly let you guys know whatever I discover, and provide submissions on any changes/fixes. If you had caught me ten or fifteen years ago, maybe I would have jumped on any perceived challenge I got. The personal satisfaction I get from my work and the great life it provides is good enough for me.Darron Black
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Don Burns
Sent: Saturday, May 06, 2006 9:53 AM
To: osg users
Subject: Re: [osg-users] First time user - VS7 - horrible memoryleaks?+Producer appears to leak GDI handles on exitMost of the Win32 code in Producer is based on user submissions. I regret to see this kind of leak and would fix it in a jiffy, but it would take me some time to narrrow things down to the point that you seem to have. Why don't you find the problem, fix it, and submit the fix and have your name emblazened on the submissions list of the CVS history?
-don
On 5/5/06, Darron Black <[EMAIL PROTECTED]> wrote:Ah. It's Producer. Somehow.I just downloaded the osgGLUT stuff. After a little porting to OSG 1.0, it works without the 11+K/sec leak that I see with Producer....I guess I'll just figure out what I need from osgGLUT to make my own Win32 render surface? :)Any new bright ideas?Object complexity doesn't seem to matter. It just leaks 11.2-11.5K/sec no matter what demo or app I am running... as long as viewer.update() and viewer.frame() are called.Darron Black
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darron Black
Sent: Friday, May 05, 2006 10:31 PM
To: 'osg users'
Subject: RE: [osg-users] First time user - VS7 - horrible memory leaks?+Producer appears to leak GDI handles on exitThanks, Edmond.I've noticed in the past that with DLLs MFC can give you erroneous leak messages if the MFC object dump happens before the DLL cleans up. That's not really a problem. I do believe that's part of what I'm seeing.However, I can watch memory usage go up at a rate of around 11.5K/sec. After 40 minutes, the application grew from 22meg to 48meg memory usage. A later test of 2h 42m showed a 108,922K gain in 2h42min, or 11.2K/sec. There's definitely a problem somewhere.Every example app I've tried so far in debug mode (OSGMFC, OSGShapes, OSGTeapot) does this.*** I just reinstalled the release binaries using osg1.0_setup_2005-12-09.exe, and even the release demo apps leak at about the same rate. ***Okay.. Worrying I had some generic ATI/OpenGL problem, I just downloaded and tried OpenSG's demos. They don't leak.Any ideas?Darron Black
Hi Darron,
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Edmond Gheury
Sent: Friday, May 05, 2006 1:23 PM
To: osg users
Subject: Re: [osg-users] First time user - VS7 - horrible memory leaks? +Producer appears to leak GDI handles on exit
I'm working exactly on the same system as you and
1. I have the same messages. I think these messages results from a confusion made by VS71 about OSG refptrs when you link your program with the MFC libs.
2. I have (had) the same problem. The code in RenderSurface_Win32 has been (partlty) fixed. This was due to the fact a WndProc wasn't registered properly... check the archive for "RenderSurface" + "MFC"
3. Never experienced that.
Best regards,
Edmond
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
