I have to agree with JS on most of this. This is not an OSG issue it's a tool issue, so no OSG should not have to be changed for this
I personally like Visual Studio and the capabilities it provides, it is a great overall, great debugging tool and also great with multiple processes and threading debugging etc , but I'm also aware it has some quirks and one of those is it is not a good tool to use for memory leaks among a couple of others. I also like Intel compiler which can be great for some things but not so great for others, so use that when there gains out ways the loses etc We use various tools for memory leaks, profiling and other issues, we have good success with Purify on our very large and complicated products But I have yet to find any memory tool that is foolproof, every one I have tried over the years has issues of some kind, so you pick your horse for the course or use a range of tools that's compliment each other and perhaps fall over on different things Gordon __________________________________________________________ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __________________________________________________________ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, February 11, 2009 10:24 AM To: OpenSceneGraph Users Subject: Re: [osg-users] memory leak false positives on Windows 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 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
