Putting a call to setGraphicsThread(0) near the top of
GraphicsWindowWin32::destroyWindow() prevents the problem. Does this
seem like a hack, or should I submit a patch? Is there any reason why a graphics thread should still be running after a graphics window has been destroyed? Cory Cory Riddell wrote: In another message thread I've been talking about a threading problem in my app. I just figured out how to reproduce it with one of the samples, so I thought I would post that here in hopes that somebody else would have an idea on how to fix this.I think it's a shutdown sequence race. To reproduce the problem, start the osgviewerMFC sample app. Load the cow, turn on stats (hit 's') then close the app. Sometimes you will get a crash. To make the crash happen all the time, add a Sleep() call to the start of the WM_DESTROY handler in MFC_OSG_MDIView.cpp:void CMFC_OSG_MDIView::OnDestroy() { Sleep(1200); if(mOSG != 0) delete mOSG; WaitForSingleObject(mThreadHandle, 1000); CView::OnDestroy(); }As far as I can see, when GraphicsWindowWin32 process the WM_DESTROY message, it sets _valid to false for the context. This prevents ~Viewer() from closing the context. This leaves a thread running and that generates an access violation because it tires to use elements that have been deleted. If the Viewer destructor is processed first, then everything is ok. This is related to the presence of a slave camera (that's why you have to turn the stats display on). Any ideas? Thanks, Cory _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org |
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org