Hello Neil,
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.
The fact that these are false positives is the key. That means that the problem is not OSG, but the memory leak detection tool. If the tool is too dense to understand that a static osg::ref_ptr<> will be deleted at the end of the program, it's not a tool worth using.
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 ?
Why would perfectly good programming practices be avoided just because they cause false positives in one tool, on one platform? This is pretty much the same discussion as the one concerning warnings I had with Robert last week.
The code should be a by-product of the design (with small allowances for language differences, of course). If the design is sound, but some tool prevents you from implementing that design in code, you should change tools, not the other way around... I personally find OSG's design very good, and it's one of the reasons I use it.
In the case of osg::Referenced memory leaks, I've posted with a few useful techniques, and Adrian Egli and others have too. Sure, they require more work than a tool that would do all that automatically, but it's better than nothing, and they're at least accurate. I guess you can always set your leak detection tool of choice to ignore osg::Referenced-derived objects, so that it will be useful for checking the rest of your application, and then check for OSG leaks using the techniques we mentioned.
Eventually, as Adrian mentioned, an "official" OSG memory leak checking tool could be written. The fact that there have been lots of posts about this lately suggests this could be useful for lots of people. But I stand by my assessment that the tools in question are at fault here. Apparently, valgrind works fine on Linux for checking OSG programs for leaks. (btw, has anyone compiled valgrind for Windows?)
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
