On 7. Feb, 2007, at 11:05 , Robert Osfield wrote:
Could you explain what system(s) you have seen this problem under. Things like OS, hardware are all important. You mentioned one machine on osg-submssions, is this the only one? Reinterating the configuration here on osg-users will help others get any idea of where the problem is occuring.
It is still the same: a MacBook Pro, ATI x1600, OS X 10.4.8, X11. I've attached a secondary monitor to the MBP. I have currently no access to another Mac.
Is the osgviewer running multi-threaded, multi-screen? Do you know which threading model its chosen?
It is all default, so I assume single-threaded, single-screen, pthreads.
I'll add text label to the stats to report this. If you press 'm' the thread model is adjusted, the new threading model being printed to the console.
It isn't ;) The application just hangs in the same place when pressing 'm': (gdb) where #0 0x90024427 in semaphore_wait_signal_trap () #1 0x90001102 in pthread_mutex_lock () #2 0x005518e3 in _XLockDisplay () #3 0x00438c61 in SendMakeCurrentRequest () #4 0x00438f97 in MakeContextCurrent ()#5 0x01023f87 in osgViewer::GraphicsWindowX11::releaseContextImplementation (this=0xe31b020) at ../GraphicsWindowX11.cpp:579 #6 0x0900703a in osg::GraphicsContext::releaseContext (this=0xe31b020) at ../GraphicsContext.cpp:277 #7 0x01040dc0 in osgViewer::Viewer::releaseContext (this=0xbffff048) at ../../../include/osgViewer/Viewer:180 #8 0x0101fa12 in osgViewer::Viewer::startThreading (this=0xbffff048) at ../Viewer.cpp:942 #9 0x0102255f in osgViewer::Viewer::setThreadingModel (this=0xbffff048, threadingModel=CullDrawThreadPerContext) at ../ Viewer.cpp:709 #10 0x00006ff9 in ThreadingHandler::handle (this=0xe307cf0, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../osgviewer.cpp:52 #11 0x00006936 in osgGA::GUIEventHandler::handle (this=0xe307cf0, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../../../include/osgGA/ GUIEventHandler:66 #12 0x0101f2e1 in osgViewer::Viewer::eventTraversal (this=0xbffff048) at ../Viewer.cpp:1856 #13 0x010218b9 in osgViewer::Viewer::frame (this=0xbffff048, simulationTime=1.7976931348623157e+308) at ../Viewer.cpp:1558 #14 0x010219e4 in osgViewer::Viewer::run (this=0xbffff048) at ../ Viewer.cpp:649
#15 0x00004f0e in main (argc=2, argv=0xbffff2cc) at ../osgviewer.cpp:208 (gdb) info threads* 1 process 486 local thread 0xf03 0x90024427 in semaphore_wait_signal_trap ()
It'd be interesting to see if some threading models have the problem, other note. If you are running across two screens try: osgviewer --screen 0 cow.osg
Well, I am running two monitors off a single GPU - afaik this is only one screen for X11.
Then see if the problem on exit occurs.
yes, as expected.
Where the trail might lead I don't know, it could be an GLX bug under OSX, it could be an osgViewer::GraphicsWindowX11 bug that isn't revealed under Linux, it could be a threading problem.
Looking at the stack trace suggest that some previous Xlib call didn't release the connection lock. Since there is only one thread running at the point of the crash (and before), this is very strange. It seems the XErrorHandler is no longer called. I have added more debug output to the handler - see attached file. I use more or less the same code in Equalizer, I tried with and without the XInitThreads() - and it works. Cheers, Stefan. -- http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann
GraphicsWindowX11.cpp
Description: Binary data
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
