[osg-users] Crash in nVidia driver : particles + dynamically adding/removing views

Jason Beverage jasonbeverage at gmail.com
Wed Nov 4 06:01:23 PST 2009

Hi J-S,

I've been having issues adding/removing Views to a CompositeViewer using
osgEarth and VPB terrain databases and have the same issues in your
example.  There is *something* going on with regards to OSG's context ID
reuse and not cleaning up resources properly.  I played around with your
example with osgEarth / VPB and found that I can open one new window fine,
close it, and then get crashes when I load the second window.  I tested with
your program and I see the same thing with the precipitation effect.  If you
change the graphics context creation code to the following and uncomment the
incrementContextIDUsageCount then your example seems to work fine with no
shared context.  This will force a new context ID to be created the next
time a graphics context is created rather than trying to reuse the previous

osg::ref_ptr<osg::GraphicsContext::Traits> traits = new
traits->x = 60;
traits->y = 60;
traits->width = 800;
traits->height = 600;
traits->windowDecoration = true;
traits->doubleBuffer = true;
osg::ref_ptr<osg::GraphicsContext> gc =
//Uncomment the next line to force the next context to use a new ID rather
than reuse a previous one
gc->getState()->getContextID() );

There is obviously something going on as your usage doesn't seem out of line
to me, but I'm not quite sure what it is.



On Wed, Nov 4, 2009 at 2:50 AM, J.P. Delport <jpdelport at csir.co.za> wrote:

> Hi J-S,
> Jean-Sébastien Guay wrote:
>> Hi all,
>> Some might recall, about a year ago, I identified a bug and provided
>> examples for nVidia to fix a bug in their driver when adding/removing views
>> (graphics contexts) at run time in a multithreaded app. That's been working
>> great for a while. Now I'm getting a crash in the nvidia driver when
>> adding/and removing views dynamically at run time, but only when the scene
>> contains an osgParticle::PrecipitationEffect (or a similar effect, such as
>> the osgOcean::SiltEffect which was derived from PrecipitationEffect).
>> I've put together an example app that demonstrates this. The code is
>> attached. Note that you need to link to osg, osgDB, osgGA, osgUtil,
>> osgViewer, osgText, osgParticle, and OpenThreads (as well as OpenGL32.lib on
>> Windows for the straight OpenGL calls present in SiltEffect.cpp).
>> The example app can be compiled to use either
>> osgParticle::PrecipitationEffect (which comes from OSG, no modification),
>> osgOcean::SiltEffect (which comes from osgOcean) or no effect. See the
>> #define USE_EFFECT at the top of the osgviewer.cpp file. Once the app is
>> running, you can press 'a' to spawn a new view (with a new graphics
>> context). Press 'a' again to remove that second view. You can in theory do
>> this many times, and it should work as many times as you want (open, close,
>> open, close, ...).
>> In my testing, the second time you spawn a new view (so pressing 'a' 3
>> times total), either the app crashes or the second view starts displaying
>> weirdly (all gray). The crash occurs in nvogl32.dll which is part of the
>> nVidia driver. Of course, when using neither PrecipitationEffect nor
>> SiltEffect, no crash occurs.
>> I can confirm that this occurs both on Windows (Vista 32bit, driver
>> 190.62) and Linux (Ubuntu 64bit, 180.44). Though on Ubuntu, the app crashes
>> much less often, but the second window displays weirdly (all gray) which
>> happens sometimes on Windows too as mentioned above.
>> Now, taking the SiltEffect for example, it seems that it's the drawing
>> itself that causes problems, because commenting out the last 2 lines of
>> SiltEffect::SiltDrawable::drawImplementation() (SiltEffect.cpp lines
>> 805-806) removes the crash (of course then the effect is not visible
>> anymore).
>> Could someone please try this example to see if they can reproduce the
>> issue?
> with
> I get the gray screen in added view on 3rd 'a'.
> output:
> $ ./test cessna.osg
> Constructing PixelBufferObject for image=0x95d67e8
> _maxTexturePoolSize=0
> _maxBufferObjectPoolSize=0
> Created new TextureObject, _numOfTextureObjects 1
> GLBufferObjectSet::GLBufferObjectSet _profile._size=131072
> GLBufferObjectSet::GLBufferObjectSet _profile._size=32768
> >>>first 'a'<<<
> Created new TextureObject, _numOfTextureObjects 1
> GLBufferObjectSet::GLBufferObjectSet _profile._size=131072
> GLBufferObjectSet::GLBufferObjectSet _profile._size=32768
> >>>second 'a'<<<
> >>>third 'a'<<<
> Reusing orhpahned TextureObject, _numOfTextureObjects=1
> Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)
> ...
> Debian 32-bit, Nvidia GeForce Go 7400, driver 185.18.36, OSG svn 10609.
> Hmm, what is strange is that the modified (extremely hacky) version
> attached does not crash and seems to work. It just uses a shared context, so
> maybe there is something in the context vs vertex array that is not working
> properly.
> jp
>> Also, if someone could check the code I have and see if something obvious
>> would cause it to crash, that would be nice. Note that SiltEffect is a
>> reduced version of osgParticle::PrecipitationEffect, but it could be nice to
>> test modifications in there to see if the same thing can be done in a
>> different way that the driver might like better.
>> In the event that everything seems good on the OSG side, I'll submit the
>> example to nVidia as a bug report, and see what they have to say.
>> Thanks in advance,
>> J-S
>> ------------------------------------------------------------------------
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
> Computers for their support.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091104/019f8531/attachment.htm>

More information about the osg-users mailing list