Hi Carsten Thank you > Hello Pan, > > li pan wrote: > > Hi, Carsten > > Thanks for you response. > > > >> I'm not really familiar with _CrtMemDumpAllObjectsSince, but according > >> to the documentation it prints information about memory that is > >> allocated. IIUC this does not mean that memory has been leaked it is > >> just in use. It would become a leak if it was not freed once it is no > >> longer needed. > > _CrtMemDumpAllObjectsSince is called by MS runtime just before the > > program exists, so it does mean memory leak. > > ok. Do you happen to know whether "just before the program exits" means > before or after destructors for global objects have run and if static > member object have been destroyed as well ? > _CrtMemDumpAllObjectsSince is supposed to run after MS CRT has unload all dlls, including OSGBase.dll. Actually it is not called by my code, it is called by MS CRT's process closing code(in debug mode). I am not sure if the memory leak exist in release version.
> >>> But 01hello.cpp itself doesn't have memory leak, what I have done is > >>> to comment all lines except osgInit() > >>> > >>> So do I always have to create a GLUT windows to avoid memory leak? > >> Hm, no. Does creating a GLUTWindow have an effect on the list of > >> allocations you see ? > > If I create a GLUTWindow, it won't print any memory leak. If there is > > a GLUTWindow, then the application quits after all windows are closed, > > maybe some code in GLUTWindow clean up the memory? > > hm, that is very confusing, GLUTWindow has no cleanup code for anything > but itself and certainly does not affect memory allocated by OSG::Log. > I'm not sure what to make of this data point. Yeah it confused me again, but it seems to me that the logging code does behave different in these two cases. I think all the dumpped objects are global objects like log . Some source in OpenSG can not be tracked by MS VC, so I not sure what are the other objects . > >>> Those memory leak are in osglog.cpp, which codes are supposed to clean > >>> up those memory block? > >> The line number in the messages above point to the constructor of > >> OSG::Log, which should only run once. It does some allocations, but > >> those basically have to remain until the program exits, because > >> otherwise logging will not be functional beyond some point, which is not > >> really desirable. > > It also has other memory leak, actually a very long list. I checked > > the code but could not figure out which code is supposed to delete log > > objects. The destructor is not called in my case. > > have you seen > <http://opensg.vrsource.org/trac/wiki/Tutorial/OpenSG1/Memleak> and also > the to FAQ linked from that document? Please understand that I'm not > trying to state that OpenSG is free of mem leaks, but in the past some > reports turned out to be just a misinterpretation of some of the > internal bookkeeping OpenSG does. I have check this page before, but I belived that what I have with the MS debug version is not related to a these problems. Because even if I do nothing except osginit, it still has some memory leak. > As far as the Log is concerned, it is very hard to avoid the leak it > has, as the logging facilities should be available even after an > application returns from main, so that destructors of global objects can > safely make use of the log. On the other hand the amount of memory > allocated by Log does not grow, so IMHO it is better to have logging as > late as possible and have the OS clean up the memory when it closes the > application process. > > Hope it helps, > Carsten > Thanks you! It seems to me that the realse version doesn' have this problem, but I may have to figure out this stuff later. Pan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
