[osg-users] osgText crash

110 views
Skip to first unread message

Chris

unread,
Oct 8, 2008, 1:09:43 PM10/8/08
to osg-...@lists.openscenegraph.org
Hi,

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

unread,
Oct 8, 2008, 1:11:40 PM10/8/08
to OpenSceneGraph Users
Chris wrote:
> 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 [...]
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

unread,
Oct 8, 2008, 1:15:03 PM10/8/08
to OpenSceneGraph Users
Hi Chris,

Are you dynamically updating the text each frame? If so set the
DataVariance to DYNAMIC.

Robert.

Paul Melis

unread,
Oct 8, 2008, 1:21:22 PM10/8/08
to OpenSceneGraph Users
Robert Osfield wrote:
> Are you dynamically updating the text each frame? If so set the
> DataVariance to DYNAMIC.
>
Hmmm, if setting it to STATIC causes a crash like this, might that be a
design flaw?

Paul

Robert Osfield

unread,
Oct 8, 2008, 1:59:18 PM10/8/08
to OpenSceneGraph Users
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.

Robert.

Chris

unread,
Oct 8, 2008, 2:04:38 PM10/8/08
to OpenSceneGraph Users
I had just read the osg archive and set the text DataVariance to DYNAMIC, with high hopes..unfortunately still crashes :(

_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

unread,
Oct 8, 2008, 2:13:01 PM10/8/08
to OpenSceneGraph Users
Hi Chris,

> 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

unread,
Oct 8, 2008, 2:13:44 PM10/8/08
to OpenSceneGraph Users
Hi Chris,

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

unread,
Oct 8, 2008, 2:13:44 PM10/8/08
to OpenSceneGraph Users
Hi Chris,

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

unread,
Oct 8, 2008, 2:17:03 PM10/8/08
to OpenSceneGraph Users
Robert Osfield wrote:
> 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.
>
Please don't get sarcastic, I did not mean to offend you.

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

unread,
Oct 8, 2008, 2:30:53 PM10/8/08
to OpenSceneGraph Users
Thanks Jean,

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

unread,
Oct 8, 2008, 2:35:03 PM10/8/08
to OpenSceneGraph Users
Hi Pail,

The default setting of DataVariance is UNSPECIFIED. There has been
lots written on this topic, please go look at the archives.

Robert,

Chris

unread,
Oct 8, 2008, 2:47:31 PM10/8/08
to OpenSceneGraph Users
Thanks Robert,

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

unread,
Oct 8, 2008, 3:05:45 PM10/8/08
to OpenSceneGraph Users
Were are you changing, adding, removing etc the text.
 
You need to ensure you are updating only in the APP thread ( not a gui thread )
From the snippet below, you need to do this in the Render function ( or that thread ) or in the Update traversal
 

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

unread,
Oct 8, 2008, 3:22:00 PM10/8/08
to OpenSceneGraph Users
Sorry if I don't quite understand the GUI/render thread distinction...(learning as I go :)

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

unread,
Oct 8, 2008, 3:32:27 PM10/8/08
to OpenSceneGraph Users
It seems from the information presented that your Basically running a multi-threaded GUI app like MFC/ WInd32 and  trying to changing something that is being accessed concurrently ( which is bad)
 
So as your key press happens in your application GUI event thread  your on timer is also firing in its thread and drawing your text, this means your changing the text at the same time your trying to draw it
 
its like getting your tires changed and trying to drive at the same time, your gonna come a cropper ;)
 
You need to do your text changes in the void render() or in an update traversal callback, you need  be able to pass data from your key press thread in a thread safe manner to your rendering thread  to indicate a key was pressed and then act on that in void render() function
 
 
 

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

 
 

Sent: Wednesday, October 08, 2008 3:22 PM

Chris

unread,
Oct 8, 2008, 3:54:41 PM10/8/08
to OpenSceneGraph Users
I don't believe there is any concurrency going on. The "on timer" is in the same thread as the key press. AFAIK it is the main app thread, i.e. the one that receives window messages. I"m using wxWidgets' wxTimer class for the timer.  There  is only one thread, and as I read the docs, it could only work from the main thread anyway (see http://docs.wxwidgets.org/stable/wx_wxtimer.html#wxtimer).

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

unread,
Oct 8, 2008, 4:25:04 PM10/8/08
to OpenSceneGraph Users
Well, looks like I am wrong. I had assumed that wxWidgets managing these timer events and executing the callbacks whenever it could from within its message dispatch thread. I did a quick test, and indeed my key event is getting called while my timer callback is active. I guess the wxTimer is actually a wrapper over the Win32 asychronous timer API or something like that.

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

unread,
Oct 9, 2008, 9:51:22 AM10/9/08
to OpenSceneGraph Users
FWIW, I take back my most recent post. Upon further research, and consultation with those on the forum for my GUI (wxWidgets), the timer event call is NOT asynchronous; (it is handled in the same thread as the key event). So there should be no concurrency problems.

Anyway, I will have to do more debugging to solve this. Thanks to all for your recent suggestions.
Reply all
Reply to author
Forward
0 new messages