[osg-users] osgText 3.6.3 crash
Trajce Nikolov NICK
trajce.nikolov.nick at gmail.com
Wed Sep 12 09:56:21 PDT 2018
Hi Robert,
That was the right hint and I must admit that I always forget it :-).
Setting the datavaraiance to osg::Object::DYNAMIC fixed the crash! As for
the other hints re performance, this is for sort of DEBUG mode for the sim
so we are ok, but thanks for these as well!
On Wed, Sep 12, 2018 at 4:09 PM Robert Osfield <robert.osfield at gmail.com>
wrote:
> Hi Nick,
>
> There are plenty of ways mutlti-thread setting of Text labels could
> cause problems if the threads reading from the Text are running in
> parallel to the ones setting it. A mutex "might" help but it could
> easily be done in the wrong way. If you are modifying text
> dynamically then you should set the DataVariance to DYNAMIC. However,
> adding mutex and using DataVariance of DYNAMIC might protect things if
> you do it all right but performance issues can easily become dominant
> as it can easily stall the various threads.
>
> It may be that trying to dynamically update Text is simply the wrong
> solution for your application. It might be that writing your own
> custom shader to implement text is the better thing to do.
>
> Robert.
>
>
>
>
> On Wed, 12 Sep 2018 at 13:24, Trajce Nikolov NICK
> <trajce.nikolov.nick at gmail.com> wrote:
> >
> > Hi Robert,
> >
> > we are experiencing some crashes in our sim software. And I know you
> will not like this post since I can not produce minimal case exercising
> this issue - I tried to mimic the sim code into one simple app but in this
> minimal app all works just great. So I will try to explain and count on you
> with hints
> >
> > The environment is multithreaded:
> > - high res thread updating labels guarded by mutex
> > - the osg threads with update callbacks on osgText::Text that is setting
> the labels with setText(...) guarded by mutex
> >
> > The env is XUbuntu 18, NVIDIA GTX 1080
> >
> > And the crash happens at
> > Text::drawImplementationSinglePass ln: 1151
> glyphquad._primitives->draw(state, usingVertexBufferObjects);
> >
> > which furthers
> >
> > DrawElementsUShort::draw ln: 266
> >
> > if (_numInstances>=1) state.glDrawElementsInstanced(mode, size(),
> GL_UNSIGNED_SHORT, (const GLvoid *)(ebo->getOffset(getBufferIndex())),
> _numInstances);
> > else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, (const
> GLvoid *)(ebo->getOffset(getBufferIndex())));
> >
> > _numInstances is 0 when the crash happens so the crash happens here:
> >
> > glDrawElements(mode, size(), GL_UNSIGNED_SHORT, (const GLvoid
> *)(ebo->getOffset(getBufferIndex())));
> >
> > Any clue or at least a thought when this can happen? Mean while I will
> continue testing and will really try again to make a small app reproducing
> this behavior
> >
> > Thanks a bunch as always!
> >
> > Cheers,
> > Nick
> >
> > --
> > trajce nikolov nick
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
trajce nikolov nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180912/12a6db55/attachment.html>
More information about the osg-users
mailing list