Hi All, As a simple user of OSG in a Microsoft VS environment, I would like to say that this one issue is the most frustrating concern I have about continuing to use OSG. I recognise that for those who don't use Microsoft VS the problem doesn't occur, but, for a large proportion of OSG users, I suspect, this is an on going problem that they, like I, encounter every single day.
I note that recently the OSG pages were updated to welcome over 2000 subscribers/users to the mailing list. I think that's wonderful, but I can't help thinking that as that number grows, more and more will be developers on a Micrsoft platform, and whose first attempts at using OSG are going to be plagued with false positive memory leaks. I can't see this as a good advert for the product - which I happen to think is seriously good. It appears that whenever this issue is raised, readers are directed to the archives to read up on the discussions, only to come away with the conclusion that we as programmers are being told that to fix the issue we really need to invest in a piece of software that doesn't fall fowl of this problem. However, I for one am deafened by the silence when it comes to someone giving a concrete recommendation as to which IDE software we should therefore purchase. As a programmer I simply want to write programmes that use Microsoft libraries, which make use of OSG, and which do not report false positives. I want a nice front end to the IDE as I am inherrantly lazy, and like point-and-click rather than command line RSI. Now, if I understand Cory's comments correctly, he has tracked some of the "issues" down to these singletons. Could someone please explain why his question regarding a restructing of these problem structures/objects doesn't deserve serious consideration ? I have wasted days - if not weeks (no exageration here at all) - in trying to track through programmes to identify what may be a memory leak, only to find that its another false positive. If a little restructuring could address the failing of the MS tools, whilst not imposing a significant overhead on other platforms, why is this not a good thing to consider ? Sorry to go on about this, but I'm currently faced with a nasty little problem as to inconsistent bahaviour between compilations of my activeX viewer that uses OSG. I'm facing the prospect of trying to track through what is happening with this nagging doubt that I'm not releasing memory when I should be, but I am swamped by the false positives. Could someone please help us with these false positives ? Thanks for listenning. If I have offended, it was not intended. Neil. ---- "Jean-Sébastien Guay" <[email protected]> wrote: > Hi Cory, > > > Can anybody recommend a Windows-based memory tracking tool? > > I have not found any tool on Windows that gave me useful results. > Perhaps that was through lack of Google-skills or whatever, but I ended > up changing osg::Referenced to keep track of where objects were > allocated/destroyed. For a start, you can enable > > #define DEBUG_OBJECT_REF_UNREF > > in src/osg/Referenced.cpp and then recompile OSG and relink with your > app. This will tell you, on the command line, each time an > osg::Referenced object (or subclass) is allocated and destroyed, as well > as a count of the number of objects that are currently allocated. You > will most likely see that the count goes down to 0 at the end of your > program, meaning there are no memory leaks. > > Those static objects you saw are not leaks, of course, and in my testing > I got anywhere between 40 and 300 of them in various places. You can > test by, for example, changing the osgviewer application so that the > whole main() function is enclosed in a block ( { } ) and then put a > breakpoint before and after that block. You will probably get a few > objects allocated before anything OSG is called in the main(), and about > 47 OSG objects still live after the block. But all those are deleted > once you exit the app. > > If you find you do have memory leaks (the memory usage of your app grows > at run time even though you shouldn't be allocating anything), then > check the osg-submissions archives for a modified osg::Referenced > header/implementation which I posted about 2 weeks ago. You can use > this to create an AllocationObserver which will be called at each ref(), > unref() and unref_nodelete() so that you can know where the call was > made. These leaks generally come from some object keeping a ref to an > object when it shouldn't, like a list/vector/map not being cleared or > whatever, so you can print out the call stack at those points, and > inspect all the results to see where the object's last ref is coming > from, for example. > > But in general, as Robert said, VS's memory leak check is crap. There > are apparently ways to fix it somewhat, but even then I wouldn't trust it. > > Hope this helps, > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
