How to debug this SIGSEGV

85 views
Skip to first unread message

Erik Hensens

unread,
May 22, 2020, 5:53:26 PM5/22/20
to OpenSceneGraph Users
Hello! I am totally at a loss and I hope someone can help me. I've got a Gtk application running on Ubuntu that uses osgGtk to display the scene. The crash does not happen every time I do the same operation, only sometimes. As you can see, the crash is in libosg. I guess that I'm doing something wrong in an Osg call somewhere and the crash is just happening asynchronously? Either way I have absolutely no idea how to approach fixing this crash. Please help me! Here's a typical backtrace. Does anyone have any ideas? Thank you all so much in advance!

- Erik

#0  0x00007fffd2e90eea in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#1  0x00007fffd2d2f5e0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2  0x00007fffd2e9ddb0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3  0x00007ffff55af488 in osg::Geometry::drawImplementation(osg::RenderInfo&) const () from /usr/lib/x86_64-linux-gnu/libosg.so.100
#4  0x00007ffff47d1380 in osgUtil::RenderLeaf::render(osg::RenderInfo&, osgUtil::RenderLeaf*) () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#5  0x00007ffff47cb695 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#6  0x00007ffff47cb6d4 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#7  0x00007ffff47d6ed7 in osgUtil::RenderStage::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#8  0x00007ffff47d5cd2 in osgUtil::RenderStage::drawInner(osg::RenderInfo&, osgUtil::RenderLeaf*&, bool&) () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#9  0x00007ffff47d7c7f in osgUtil::RenderStage::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#10 0x00007ffff47dfdb7 in osgUtil::SceneView::draw() () from /usr/lib/x86_64-linux-gnu/libosgUtil.so.100
#11 0x00007ffff443545f in osgViewer::Renderer::cull_draw() () from /usr/lib/x86_64-linux-gnu/libosgViewer.so.100
#12 0x00007ffff55cfd49 in osg::GraphicsContext::runOperations() () from /usr/lib/x86_64-linux-gnu/libosg.so.100
#13 0x00007ffff446c6c4 in osgViewer::ViewerBase::renderingTraversals() () from /usr/lib/x86_64-linux-gnu/libosgViewer.so.100
#14 0x0000000000a7c73e in osgViewer::ViewerGtk::on_graphics_window_expose_event (widget=0x31134b0, event=0x7fffffffdf10, data=0x456ba50) at Main3D/osgGtk/ViewerGtk.cpp:220
#15 0x00007ffff78beaec in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#16 0x00007ffff6904fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff6916fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff691f7f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff692008f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff79d693c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#21 0x00007ffff78bd7dd in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#22 0x00007ffff7518b9f in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#23 0x00007ffff7515671 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#24 0x00007ffff7515fa8 in gdk_window_process_all_updates () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#25 0x00007ffff7842971 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#26 0x00007ffff74f4d57 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#27 0x00007ffff662e04a in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007ffff662e3f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007ffff662e712 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x00007ffff78bc697 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#31 0x000000000130f9a6 in main (argc=1, argv=0x7fffffffe398) at Main/main.cpp:3889



Brett Gossage

unread,
May 23, 2020, 1:59:21 AM5/23/20
to osg-...@googlegroups.com
Build in debug mode.  Run it under valgrind:   valgrind  <your app>  arg1 arg2 ...

Go through the steps necessary to duplicate the error.

You'll get a call stack output to the console with the origin of the error. (hopefully)

Good luck.






--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/eab20cdb-8864-4eca-94c6-6e74dc6601cd%40googlegroups.com.

Mauricio Franco

unread,
May 23, 2020, 2:30:34 AM5/23/20
to osg-...@googlegroups.com
remove or hide some nodes (setting nodemask to 0) from your scenegraph until you find the one causing the issue.

Use a StateSetHandler to turn on or off rendering features.

Make sure the opengl context is current every time you update/render the scene graph.

Capture osg logging.

Looks like it happens during the rendering of a VBO in a osg::Geometry.

Sent from my iPhone

On May 22, 2020, at 10:59 PM, Brett Gossage <bgos...@gmail.com> wrote:



OpenSceneGraph Users

unread,
May 25, 2020, 12:13:17 PM5/25/20
to osg-...@lists.openscenegraph.org
Hi, Erik. Could it be that you are adding and/or removing entities in
your scene at run time?

Have you used valgrind? It will be very slow, but can shed some light
about the issue.

--
Alberto

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Erik Hensens

unread,
May 26, 2020, 10:00:41 AM5/26/20
to OpenSceneGraph Users
Thanks for the suggestion, Brett. Unfortunately, because the application interacts with external sensors in real time, running Valgrind is nearly impossible because of how slow it makes the application run, thereby causing timing issues with the sensors that prevent required operations from finishing (required to replicate the bug).
To unsubscribe from this group and stop receiving emails from it, send an email to osg-...@googlegroups.com.

Erik Hensens

unread,
May 26, 2020, 10:02:51 AM5/26/20
to OpenSceneGraph Users
Thank you, Mauricio! I'll consider removing or hiding nodes one at a time, but because there are just so many I'm afraid it won't be practical.

I don't know about the OpenGL context being current, but I will learn about this. Thanks for the suggestion!
To unsubscribe from this group and stop receiving emails from it, send an email to osg-...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-...@googlegroups.com.

Erik Hensens

unread,
May 26, 2020, 10:04:31 AM5/26/20
to OpenSceneGraph Users
Thank you, Alberto. I am adding and removing nodes from the scene in real time. Is that a problem?

As for Valgrind, please see my response to Brett, replicated here: "Unfortunately, because the application interacts with external sensors in real time, running Valgrind is nearly impossible because of how slow it makes the application run, thereby causing timing issues with the sensors that prevent required operations from finishing (required to replicate the bug)."

But I appreciate your suggestion.

Erik Hensens

unread,
May 26, 2020, 11:25:12 AM5/26/20
to OpenSceneGraph Users
Mauricio, could you please provide some guidance (maybe a small example) of how to ensure that the opengl context is current every time I update/render? Thank you so much.

Erik Hensens

unread,
May 26, 2020, 11:55:08 AM5/26/20
to OpenSceneGraph Users
Also, when I do not get the crash, I do get the following warning:

Warning: detected OpenGL error 'invalid value' at after RenderBin::draw(..)

Maybe there's some connection? How do I go about finding the invalid value that is mentioned here?

Thank you!

OpenSceneGraph Users

unread,
May 27, 2020, 10:51:26 AM5/27/20
to osg-...@lists.openscenegraph.org
OpenSceneGraph Users writes:

> Thank you, Alberto. I am adding and removing nodes from the scene in real time. Is that a problem?

Yes, it is if you are not using a SingleThreaded viewer mode. It could
be that some thread is trying to access a just deleted node.

Erik Hensens

unread,
May 27, 2020, 2:59:48 PM5/27/20
to OpenSceneGraph Users
Thanks, Alberto. I changed my viewer to use the SingleThreaded threading model (it had been using ThreadPerContext) but the problem remains. Thanks for the advice anyway!

OpenSceneGraph Users

unread,
May 28, 2020, 3:22:48 PM5/28/20
to OpenSceneGraph Users
Hi Erik,

I have seen the exact crash when I provide non-valid data for primitive sets in geometry. Something like drawarray with 0 size. OSG is not checking the validity of all the data (I believe the reason is performance). So maybe you put validation of your data before letting osg render it

And I just read you are updating the scenegraph in realtime. Make sure this is done in the update traversal (you can do this in Node UpdateCallbacks) or decompose the viewer.frame() and add your update code at the beginning of the decomposed frame()

Hope this helps

On Tue, May 26, 2020 at 7:11 PM OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:
Also, when I do not get the crash, I do get the following warning:

Warning: detected OpenGL error 'invalid value' at after RenderBin::draw(..)

Maybe there's some connection? How do I go about finding the invalid value that is mentioned here?

Thank you!

On Friday, May 22, 2020 at 4:53:26 PM UTC-5, Erik Hensens wrote:

--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/c845db03-c6e4-4142-b681-66aeff9988fd%40googlegroups.com.

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


--
trajce nikolov nick

Erik Hensens

unread,
May 29, 2020, 2:47:22 PM5/29/20
to OpenSceneGraph Users
Hi Trajce,

Thank you so much for this advice! I will immediately begin looking into any invalid data for primitive sets.

Also, I had no idea that you weren't supposed to update the scene outside of the update callback... this is great advice. I will have to do major changes to pull that off. It's been working fine up until now, I guess I've just been lucky.

Thanks again!
To unsubscribe from this group and stop receiving emails from it, send an email to osg-...@googlegroups.com.


--
trajce nikolov nick

Erik Hensens

unread,
May 29, 2020, 3:25:12 PM5/29/20
to OpenSceneGraph Users
One thing I just noticed was in osgAnimation/StatsHandler:

                if (geometry->getNumPrimitiveSets() == 0)
                    geometry->addPrimitiveSet(new osg::DrawArrays(GL_LINE_STRIP, 0, 0));

in line 203 in v 3.2.1.100

Here, the new draw arrays is provided a size of zero (isn't this a no-no?) and also it is created not as a reference pointer. Am I missing something? This looks like bad form?


On Thursday, May 28, 2020 at 2:22:48 PM UTC-5, OpenSceneGraph Users wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to osg-...@googlegroups.com.


--
trajce nikolov nick
Reply all
Reply to author
Forward
0 new messages