I'm getting one of these problems again so let me elaborate a little bit.  I
am generalizing about several types of bugs that we have seen in this
category.

 

Our OSG based application currently works fairly reliably on several
machines.  Occasionally when we try operating on a new machine, we observe a
reliable crash when starting up the application.  When we begin to
investigate the crash using a debugger we find that the crash occurred in
ig4icd32.dll (the Intel driver) or sometimes it's the nVidia driver (I
forget the name nvogl something).  Usually when this happens the first thing
we do is update the graphics driver on the machine having the crash.
Sometimes this fixes the problem, sometimes it doesn't.  When it doesn't we
general conclude that there is some bug in the gl driver for that gpu
(because the app works elsewhere).  Now I'm not trying to hassle anyone
about including workarounds for bad drivers in the OSG.  Instead when we see
a crash while rendering (from the rendergraph) it would be nice if there was
some way to trace (in the debugger) back to the offending piece of the
scenegraph.  So far I have not been able to do this.  Instead I have really
only had success by selectively adding/removing pieces from our application
(process of elimination) which tells me what piece of the scene graph the
crash is associated with.  Then I will generally find out something like
that piece is using fbo or npot or doing something bad or whatever in some
way that is causing the crash.

 

Now looking in the debugger for the immediate crash at hand I get something
like the error and stack trace shown below.  What do I know from this
information?  Well the crash occurred in the Intel GL driver and ostensible
it happened while osg was drawing UShort elements.  I can inspect the state
variable and know some stuff about the rendering state.  Now I want to
divine which piece of the scene graph this crash is associated with.  I get
that not all render time crashes directly correlate to something in the
scene graph but when osg runs and works until you add a certain thing, then
in my mind there is some correlation.  In the case below, what osg drawable
were these Ushort elements associated with?

 

Thanks

-Brad



 

                ig4icd32.dll!06e3c809() 

                [Frames below may be incorrect and/or missing, no symbols
loaded for ig4icd32.dll]        

               ig4icd32.dll!06e2b98e()                 

                ig4icd32.dll!06e40478() 

                ig4icd32.dll!06e58236() 

                ig4icd32.dll!06e59daa() 

                KERNELBASE.dll!_GlobalAlloc@8()  + 0x74 bytes


               KERNELBASE.dll!_GlobalAlloc@8()  + 0x74 bytes                

               ig4icd32.dll!06e5a713() 

                ig4icd32.dll!06f8b382()   

                ig4icd32.dll!06f8b96f()   

                ig4icd32.dll!06f8bafc()    

                ig4icd32.dll!06f8bd8e() 

                ig4icd32.dll!06f8a192()   

                ig4icd32.dll!0773121d() 

                ig4icd32.dll!070429fb()   

                ig4icd32.dll!06f8a0f4()    

                ig4icd32.dll!07731189() 

                ig4icd32.dll!07042282() 

                ig4icd32.dll!07042438() 

                ig4icd32.dll!0704245f()   

                ig4icd32.dll!077326de() 

                ig4icd32.dll!06f85bd9() 

                ntdll.dll!@RtlpFreeUserBlock@8()  + 0x73 bytes


               ig4icd32.dll!06f82d11()   

                ntdll.dll!@RtlpLowFragHeapAllocFromContext@8()  + 0x123
bytes           

               ntdll.dll!_RtlAllocateHeap@12()  + 0xac bytes     

               ig4icd32.dll!06dcea9b() 

                ig4icd32.dll!06e14b03() 

                ig4icd32.dll!06ee99a6() 

                ig4icd32.dll!06ee9a2a() 

                ig4icd32.dll!06f83033()   

                ig4icd32.dll!06eefafe()   

                ig4icd32.dll!06da6b6e()                 

                ig4icd32.dll!06da1424() 

                ig4icd32.dll!06dba70d()                 

                ig4icd32.dll!076453e1() 

                ig4icd32.dll!07649bdb()                 

                ig4icd32.dll!072a6866() 

                ig4icd32.dll!071ab105() 

                ig4icd32.dll!0721da71() 

                ig4icd32.dll!0721dd53() 

                ig4icd32.dll!0721e188() 

                ig4icd32.dll!0721e84a() 

                ig4icd32.dll!07220e42() 

                ig4icd32.dll!0721e87b() 

>             osg73-osgrd.dll!osg::DrawElementsUShort::draw(osg::State &
state={...}, bool useVertexBufferObjects=true)  Line 249 + 0x2e bytes
C++

 
osg73-osgrd.dll!osg::Geometry::drawImplementation(osg::RenderInfo &
renderInfo={...})  Line 1122 + 0xf bytes                C++

               osg73-osgrd.dll!osg::Drawable::draw(osg::RenderInfo &
renderInfo={...})  Line 916 + 0xa bytes C++

 
osg73-osgUtilrd.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo &
renderInfo={...}, osgUtil::RenderLeaf * & previous=0x00000000)  Line 480
C++

 
osg73-osgUtilrd.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
& renderInfo={...}, osgUtil::RenderLeaf * & previous=0x00000000)  Line 1367
C++

 
osg73-osgUtilrd.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo &
renderInfo={...}, osgUtil::RenderLeaf * & previous=0x00000000, bool &
doCopyTexture=false)  Line 936    C++

 
osg73-osgUtilrd.dll!osgUtil::RenderStage::draw(osg::RenderInfo &
renderInfo={...}, osgUtil::RenderLeaf * & previous=0x00000000)  Line 1208
C++

               osg73-osgUtilrd.dll!osgUtil::SceneView::draw()  Line 1443 +
0x15 bytes  C++

               osg73-osgrd.dll!osg::Stats::collectStats(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
str={...})  Line 80 + 0x4a bytes     C++

               osg73-osgViewerrd.dll!osgViewer::Renderer::cull_draw()  Line
849         C++

               osg73-osgrd.dll!osg::GraphicsContext::runOperations()  Line
751              C++

 
osg73-osgViewerrd.dll!osgViewer::ViewerBase::renderingTraversals()  Line 809
+ 0x17 bytes     C++

               osg73-osgViewerrd.dll!osgViewer::ViewerBase::frame(double
simulationTime=2.2281973105867356e-303)  Line 643         C++

               osg73-osgViewerrd.dll!osgViewer::ViewerBase::frame(double
simulationTime=6.5245075982572160e-306)  Line 645 + 0x9 bytes C++

               KERNELBASE.dll!_OutputDebugStringA@4()  + 0x60 bytes


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Robert
Osfield
Sent: Monday, June 06, 2011 11:51 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] General render debugging question

 

Hi Brad,

 

On Mon, Jun 6, 2011 at 11:27 PM, Brad Huber < <mailto:[email protected]>
[email protected]> wrote:

> I'm currently trying to track down a render-time application crash.  

> What I'm wondering is how to trace from a crash in the rendergraph to 

> the associated node(s) in the scene graph.  Is there any straight forward
way?

 

The crash could be for any reason, it may or may not be related to the scene
graph at all.

 

Personally I use a debugger and get a strack trace to get an idea of where
the crash is and then from this investigate.  There is no automagic way of
knowing exactly what is causing a crash, nor is there a way of automatically
knowing what you are doing with the scene graph that may or may not be
causing a crash.

 

If a straight debugger doesn't give you enough clues then you could look at
using a memory/thread analsyis tool like valgrind, or an OpenGL debug tool
like gDEBugger.

 

Also just observing the app when it crashes and looking to see if there is
any correleations that might give you a clue.  All it's just dtective work.

 

Robert.

_______________________________________________

osg-users mailing list

 <mailto:[email protected]>
[email protected]

 <http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

<<image001.png>>

_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to