[osg-users] osgText crash
Chris
I'm having semi-random crash bugs when I add an osgText drawable to my scene. The actual error is a mem access violation, and it occurs after I've added & removed the node containing the drawable from the scene a random number of times' (usually from 1 to 10 times)
The exception occurs in the same place in the call stack, apparently somewhere in my open gl .dll (nvoglnt.dll). One thing that puzzles me is that I'm using SWIG, and from the call stack the function PySwigObject_Check(PyObject *op) ) seems to call into the osgUtil .dll, which in about 10 stack layers ends up calling nvoglnt.dll. I don't know why 'PySwigObject_Check' would be caling the osg .dll, (see func copied below), but maybe some sort of wierd thread confusion ?
SWIGRUNTIMEINLINE int
PySwigObject_Check(PyObject *op) {
return ((op)->ob_type == PySwigObject_type())
|| (strcmp((op)->ob_type->tp_name,"PySwigObject") == 0);
}
The crash does NOT occur if I repeatedly create/delete the osgText drawable but don't add it to my scene. It does not crash during the render but seems to corrupt something that fails elsewhere (apparently in 'PySwigObject_Check' )
While I can't be certain it's not my code, I have been running the same render code (which uses osg) now for a few years without problems. Note that I dont explictly create extra threads in my code, beyond what osg might be doing.
I thought this looked like some thread/mutex problem, or pehaps a VC++ STL problem (anyone had these issues with osg Text before?) I created a new version of osgText that hacks out the STL-based 'String' class used to 'setText', but no dice.
I was running on WinXP, using compiler: Visual Studio .net 2002. I just installed Osg 2.7.1, and Visual Studio Express 9.0; but the crash still occurs.
TIA,
Chris
--
www.sketch3.com
Paul Melis
> I'm having semi-random crash bugs when I add an osgText drawable to my
> scene. The actual error is a mem access violation, and it occurs after
> I've added & removed the node containing the drawable from the scene a
> random number of times' (usually from 1 to 10 times)
>
> The exception occurs in the same place in the call stack, apparently
> somewhere in my open gl .dll (nvoglnt.dll). One thing that puzzles me
Does your SWIG wrapper handle the reference counting needed to correctly
work with drawables and nodes?
Paul
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Robert Osfield
Are you dynamically updating the text each frame? If so set the
DataVariance to DYNAMIC.
Robert.
Paul Melis
> Are you dynamically updating the text each frame? If so set the
> DataVariance to DYNAMIC.
>
design flaw?
Paul
Robert Osfield
> Hmmm, if setting it to STATIC causes a crash like this, might that be a
> design flaw?
Is a design constraint for when running in DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext threading models as these
threading models use the DataVariance of StateSet and Drawable to
decide when it's safe to let the next frame advance. Lots has been
written on this topic on the mailing list over the past year and half.
If it you think it's a "flaw" then you just just stick to
SingleThreaded or CullDrawThreadPerContext threading models and forgo
the performance benefit that this "flaw" provides.
Robert.
Chris
_text->setDataVariance(osg::Object::DYNAMIC);
I create my Text in response to a keystroke, and add it to the scene. The next keystroke removes and deletes it. Each time I create it, the initial rendered text string does not change.
( Also set my loaded osgText::Font to DYNAMIC DataVariance, doesn't help. )
BTW I noticed there were some nvidia problems in the archives; I do have an NVidia driver (my machine is a Toshiba Tecra M4, Geforge Go 6200 (three years old), driver date 3/14/2005, version 7.1.4.1 )
as per your StateSet DataVariance comment, should i do that as well ? I'm not familiar with osg's thread models, but I just call render within my app's main thread, and I dont' explicitly create other threads myself.
Jean-Sébastien Guay
> I create my Text in response to a keystroke, and add it to the scene.
> The next keystroke removes and deletes it. Each time I create it, the
> initial rendered text string does not change.
This is more of a workaround than an actual fix, but why are you
adding/removing/deleting the object in that case? Why not just add it
once, and then set its node mask to 0 when it should not be visible and
0xFFFFFFFF when it should be? Or add it under an osg::Switch and use
that when you need to control whether it's visible or not.
For that matter, even if the text string changed, I'd do it that way if
I needed a keypress to control visibility of the osgText::Text. No use
adding/removing things from the scene graph in that case, as the node
mask or osg::Switch will have the same result (rendering cost will be
virtually nil).
> BTW I noticed there were some nvidia problems in the archives; I do have
> an NVidia driver (my machine is a Toshiba Tecra M4, Geforge Go 6200
> (three years old), driver date 3/14/2005, version 7.1.4.1 <http://7.1.4.1> )
You might want to update your video card driver, I don't know if 7.1.4.1
is accurate but we're now in the 170.xx range, and in particular
threading issues related to the graphics driver were very frequent in
older releases (because they were not often tested in multithreaded
contexts, since apps that took advantage of multithreading were less
widespread than they are now).
It's just a shot in the dark of course, but it might help.
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
Robert Osfield
With so few details about your viewer setup and scene graph usage the
best we can do is guess what you might have done wrong given other
common mistakes we see pop up - have the DataVariance recommendation.
Another thing you could try setting the threading model on the viewer
by calling
viewer.setThreadingMode(osgViewer::Viewer::SingleThreaded);
Again it's a long shot given we really don't know enough about the OSG
version you are using, which viewer library/classes and the fact
you're trying to control everything thing through swig wrappers.
Robert.
Robert Osfield
With so few details about your viewer setup and scene graph usage the
best we can do is guess what you might have done wrong given other
common mistakes we see pop up - have the DataVariance recommendation.
Another thing you could try setting the threading model on the viewer
by calling
viewer.setThreadingMode(osgViewer::Viewer::SingleThreaded);
Again it's a long shot given we really don't know enough about the OSG
version you are using, which viewer library/classes and the fact
you're trying to control everything thing through swig wrappers.
Robert.
Paul Melis
> On Wed, Oct 8, 2008 at 6:21 PM, Paul Melis <pa...@science.uva.nl> wrote:
>
>> Hmmm, if setting it to STATIC causes a crash like this, might that be a
>> design flaw?
>>
>
> Is a design constraint for when running in DrawThreadPerContext or
> CullThreadPerCameraDrawThreadPerContext threading models as these
> threading models use the DataVariance of StateSet and Drawable to
> decide when it's safe to let the next frame advance. Lots has been
> written on this topic on the mailing list over the past year and half.
>
> If it you think it's a "flaw" then you just just stick to
> SingleThreaded or CullDrawThreadPerContext threading models and forgo
> the performance benefit that this "flaw" provides.
>
I'm merely looking at this from a user perspective, in which an object
member can take on two values where one value (DYNAMIC) provides an
optimization that might not be of immediate interest to the average OSG
user, while the default setting (STATIC) causes OSG to exit with cerain
(ok, non-standard) threading models. And updating text values during
rendering does seem like a fairly straightforward operation that should
not result in too many surprises.
Would it be a solution to set the data variance to DYNAMIC as soon as
the text's value is set the second time?
Regards,
Paul
Chris
The adding / removing / deleting is because I am using it to enter typed text. You're right, I don't have to actually delete the Text drawable each time I'm finished entering text, but I do need to set it's text repeatedly in response to my typing. I have a feeling it would crash anyway if I just called 'setText'. I'll try that and see what happens. Thanks for the suggestion.
One problem I see with the visibllity mask approach is that I have an arbitrary number of scenes being rendered, and I want to add any number of user definable text annotations to arbitrary points in each scene; in other words, it's not just one single predictable place/node where my text "lives". At some point I'd have to create new ones and delete old ones.
The crash still makes me nervous, even if that works :)
I just checked; the only official driver update for my Geforce Go 6200 is a minor one from the Toshiba website (at least Nvidia's website driver search tool tells me to go there.) I guess the newer Nvidia ones (170.xx) don't support the "Go" versions of the chipsets...
Robert Osfield
The default setting of DataVariance is UNSPECIFIED. There has been
lots written on this topic, please go look at the archives.
Robert,
Chris
I do realize it's tough to tell without seeing the code. Up to yesterday I used osg 2.1, but just upgrade to 2.7.1 (bug still occurs). FWIW, I'm not using the viewer setup in the examples, I use my own osgUtil::SceneView and use cull & draw directly. Note I setup my viewport properties on each rendered frame, as these are animated. The basic code is like:
void render()
{
osgProducer::OsgSceneHandler *sh = dynamic_cast<osgProducer::OsgSceneHandler *> ( _cam.getSceneHandler() );
osgUtil::SceneView* sv = sh->getSceneView();
sv->setSceneData( (osg::Node *) getSceneNode(0) );
osg::State* state = sv->getState();
state-> dirtyColorPointer();
sv->setProjectionMatrix( projection );
sv->setViewMatrix( *_viewMatrix );
sv->setViewport( clippedViewport.x, clippedViewport.y, clippedViewport.xdim, clippedViewport.ydim );
//sv->update(); no anims, no need to update ?
sv->cull();
sv->draw();
Tomlinson, Gordon
Gordon
__________________________________________________________
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__________________________________________________________
(C):
(+1) 571-265-2612
(W):
(+1) 703-437-7651
"Self defence is not a
function of learning tricks
but is a function of how
quickly and intensely one
can arouse one's instinct
for survival"
- Master Tambo Tetsura
From: osg-user...@lists.openscenegraph.org [mailto:osg-user...@lists.openscenegraph.org] On Behalf Of Chris
Sent: Wednesday, October 08, 2008 2:48 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgText crash
Chris
Pseudo code for adding/deleting is as follows, (all in the same (and only) thread,which receives GUI events)
on_key_press()
{
toggle = ! toggle
if (toggle)
addTextToScene()
else
removeAndDeleteTextFromScene()
}
on_timer_event() // timer event occurs 30 times a second
{
renderScene() (calls the render function I quoted earlier)
Tomlinson, Gordon
Gordon
__________________________________________________________
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__________________________________________________________
(C):
(+1) 571-265-2612
(W):
(+1) 703-437-7651
"Self defence is not a
function of learning tricks
but is a function of how
quickly and intensely one
can arouse one's instinct
for survival"
- Master Tambo Tetsura
Chris
In any event, I am reviewing the wxWidgets docs to see if there is a chance the timer callback is in it's own thread, but the docs so far don't mention that.
Chris
OK, I feel foolish...but yes, I did understand that unmanaged, concurrent acess to data is bad . Thanks for pointing this out. :)
What's very strange is this was never a problem before, as I've made many scene changes this way in the 4-year history of my app.
Chris
Anyway, I will have to do more debugging to solve this. Thanks to all for your recent suggestions.