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 ? >>> 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. >>> 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. 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 ------------------------------------------------------------------------- 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
