Hi Brian, I wouldn't worry too much about scene graph destruction, this is likely to be working just fine unless the compiler has screwed up. Scene graph memory management is a pretty thoroughly exercised and bedded down part of the OSG, so if there are problems here there is a good chance its just a symptom of problems elsewhere.
The news parts of the code are osgViewer, and in particular the threading and graphics window management. So this is the most likely place of any new issues that have been introduced. osgViewer has undergone a huge amount of development of the past months and during the last couple weeks has been bedding down, with various bugs being fixed, in particular around the window, graphics context and threading management. Touch wood things are now working pretty stable under Windows (VS build), Unix and OSX, even when running mulit-threaded. Due to all these improvements I'd strongly recommend keeping up to date with the latest in SVN as there is always that the problems you are seeing have been fixed thanks to other improvements. So the next question has to be which version are you working with right now? Another note, the run method is a simply frame loop that just iterates until the Viewer _done is set to true - have a look at the code in src/osgViewer/Viewer.cpp. I don't think this be a factor in the hang. Most likely its the threads not cancelling for some reason. Robert. On 2/21/07, Brian Keener <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED]> Robert Osfield wrote: > The debug output doesn't look too suspicious. A stack trace is what > is really required. Well, in addition to the programs that I posted that do and do not terminate successfully Ihave also managed to find at least come up with this. Several that I have looked at that do and do not terminate all have as the last line (or nearly last line ) - in this case this is from osghangglide return viewer.run() if you do a bt in the debugger immediately on return from this line you get: (gdb) bt #0 main (argc=1, argv=0x12294610) at ../osghangglide.cpp:185 and you will be at the main closing brace and then by stepping you get: (gdb) s 0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll (gdb) bt #0 0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll #1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll #2 0x00000000 in ?? () (gdb) As I say the above is from osghangglide (which does not hang) and when I step through osgviewer and osgwindows which also both use return viewer.run() at the end of their main and do a bt I get the same as above. I have inserted a lot of osg::notify in the code attempting to trace this further and I am now curious about Group. When a group is destructed is its children supposed to be destructed too - should the children count decrease each time the parent reference is remove from one - should there be a lot of Groups created that never seem to have any children added. I won't burden you with the output (well actually I did - couldn't resist) but in osghangglide I can see groups created and children added and then I can see the parent child link being removed but the child count never decrements on the parent. Where as in osgwindows I see a lot of groups created that never have any children added. Just trying to get a handle on what those groups are. For example the end of osghangglide with my notifies shows this: Group::~Group() for group 0x122975b0completing with 4 to 4 Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() for group 0x12297648completing with 1 to 1 Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() for group 0x122977e0completing with 2 to 2 Image::~Image() completing Image::~Image() completing Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() removing Parent for iterator which has 1 parents Group::~Group() for group 0x1229c628completing with 9 to 9 Image::~Image() completing Image::~Image() completing Image::~Image() completing Win32WindowingSystem::~Win32WindowingSystem() completing [EMAIL PROTECTED] /usr/src/OpenSceneGraph/src $ but notice the end of osgwindows with my notifies looks like this: Image::~Image() completing Group::~Group() for group 0x122a1308completing with 0 to 0 Group::~Group() for group 0x122a0cb0completing with 0 to 0 Group::~Group() for group 0x122a0728completing with 0 to 0 Group::~Group() for group 0x122a03b0completing with 0 to 0 Group::~Group() for group 0x1229fd18completing with 0 to 0 Group::~Group() for group 0x1229fa80completing with 0 to 0 Group::~Group() for group 0x1229efd8completing with 0 to 0 Program::~Program() finishing with 0 shaders Projection::~Projection() terminating Group::~Group() for group 0x1229ea28completing with 0 to 0 Group::~Group() for group 0x1229e7c0completing with 0 to 0 Group::~Group() for group 0x1229e340completing with 0 to 0 Group::~Group() for group 0x1229c788completing with 0 to 0 Group::~Group() for group 0x1229b940completing with 0 to 0 Group::~Group() for group 0x12299760completing with 0 to 0 Viewport::~Viewport() terminating Not sure if any of this makes sense but trying to piece it together and the one thing I notice above is that at the end of osgwindows I never see the line for Win32WindowingSystem::~Win32WindowingSystem() completing since I have to kill it at the above Viewport::~Viewport() line. > A little bit of hope is that perhaps the hang on exit you see if > related to the OSX X11 hang on exit. Well in this case we are not attempting to use the X11 for Cygwin but simply keeping in the standard windows logic. bk _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
