Hi Stefan, Is you machine dual core or single core?
On 2/7/07, Stefan Eilemann <[EMAIL PROTECTED]> wrote:
> 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 first time StatsHandler is invoked is has to stop threading, then add a new HUD camera to the first graphics window, then its restarts any threading if required. So.. it obviously pressing the same problematic buttons as exiting is. Still a useful another point on the map.
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 ()
Another point on the map... The above suggests that original mode was probably single threaded. It might be worth adding some debugging to get a definitive answer. Note that the osgViewer::Viewer now by default automatically suggests the threading model to use, if you have a single core machine and single window it suggest SingleThreaded. Not sure what it all means yet though...
> osgviewer --screen 0 cow.osg Well, I am running two monitors off a single GPU - afaik this is only one screen for X11.
The above should just open on one window on screen 0. Is this what happens?
> > 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.
If only I could recreate the same problem then I might have a chance to dig what might be up. I have single core Linux laptop that I fire occassional, and everything works fine save for the exit from osgwindows. Here a get a crash in the OpenGL driver. No clue to cause yet. What happens when you run osgwindows cow.osg?
It seems the XErrorHandler is no longer called. I have added more debug output to the handler - see attached file.
Thanks for the file, I'll review it with view to merging it with CVS.
I use more or less the same code in Equalizer, I tried with and without the XInitThreads() - and it works.
Do you have completely your own X11 viewer code in Equalizer, or does this sit ontop of the OSG's viewer lib? Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
