[osg-users] Dev release 2.1.9 feedback: Two minor problems
robert.osfield at gmail.com
Tue Sep 4 01:44:13 PDT 2007
On 9/4/07, Murray Curtis <murrayml at dragtag.com.au> wrote:
> Minor thing one:
> Everything compiles fine but theres a warning when I compile my app:
> osgUtil/StateGraph: In constructor 'osgUtil::StateGraph::StateGraph()':
> osgUtil/StateGraph:99: warning: 'osgUtil::StateGraph::_stateset' will be
> initialized after
> osgUtil/StateGraph:51: warning: 'int osgUtil::StateGraph::_depth'
> osgUtil/StateGraph:62: warning: when initialized here
> This is on Linux 2.6.15-28 with GCC 4.0.3.
Just a minor rearrangement of variables has caused this. I've now
rearranged them again and checked it into SVN.
> Minor thing two:
> On one particular series of systems, linux 2.6.11 with gcc 3.3.4, nvidia
> opengl I get:
> Xlib: unexpected async reply (sequence 0x2a)!
> Google tells me this is apparently due to making X calls from more than
> one thread.
> I tracked this down to osgViewer auto selecting DrawThreadPerContext for
> its threading model. Making it SingleThreaded fixed it. Funny thing was
> if I stepped through the init process in the debugger the error didn't
> occur - a real Heisenbug!
The error "Xlib: unexpected async reply (sequence 0x2a)!" is a
familiar one, not of late, but over the years it reared its head a
number of time.
The issue comes down to Xlib by default not being set up for
multi-threaded use per display connection, if you want multi-threaded
support per display connection then you need to enable it it via
XInitThreads(). src/osgViewer/GraphicsWindowX11.cpp has such a call
comment out right now as in theory it should not be needed. Although
the osgViewer does support multi-threaded usage of X11 it tries
manages two display connections - one for rendering, and one for event
handling so in theory each connection should only have one thread
The fact you are getting an error suggest that in certain timings the
wrong display connection is used by the wrong thread. The big
question is where is the offending bit of code... as just putting the
code in a debug changes the timing enough that the condition no longer
If I was able to reproduce this at my end I might have a chance at
tracking it down, but I haven't seen a async reply for several months
In your own app you could try adding a XInitThreads at the start of
the app and see if this cures things. In theory there can be a
performance overhead with doing this, but so far I haven't measured a
significant hit in the way that osgViewer uses it.
More information about the osg-users