Created attachment 91869 [details] full konsole output of a session with a crash Running latest FlightGear git version on openSUSE 13.1 with Mesa-10.1~git20140110-1.1.x86_64, libLLVM35-3.5~svn20140107-1.1.x86_64, llvm-r600-3.5~svn20140107-1.1.x86_64, libdrm2-2.4.99~git20131225-1.2.x86_64 and kernel 3.13.0-rc7-6.g57a2f1c-desktop on a Radeon HD 5670 I get segfaults at seemingly random points. The backtrace always looks like this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffebb61700 (LWP 10909)] 0x00007fffee1d5d23 in _save_Normal3fv (v=0x0) at vbo/vbo_attrib_tmp.h:340 340 vbo/vbo_attrib_tmp.h: No such file or directory. (gdb) bt #0 0x00007fffee1d5d23 in _save_Normal3fv (v=0x0) at vbo/vbo_attrib_tmp.h:340 #1 0x00007fffee0df589 in _ae_ArrayElement (elt=0) at main/api_arrayelt.c:1714 #2 0x00007fffee1cf690 in _save_OBE_DrawArrays (mode=<optimized out>, start=<optimized out>, count=<optimized out>) at vbo/vbo_save_api.c:1103 #3 0x00007ffff52ea0ed in osg::DrawArrays::draw(osg::State&, bool) const () from /opt/FlightGear/lib64/libosg.so.100 #4 0x00007ffff52341fa in osg::Geometry::drawImplementation(osg::RenderInfo&) const () from /opt/FlightGear/lib64/libosg.so.100 #5 0x00007ffff68b8780 in osg::Drawable::draw(osg::RenderInfo&) const () from /opt/FlightGear/lib64/libosgParticle.so.100 #6 0x00007ffff623ea98 in osgUtil::RenderLeaf::render(osg::RenderInfo&, osgUtil::RenderLeaf*) () from /opt/FlightGear/lib64/libosgUtil.so.100 #7 0x00007ffff623312c in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #8 0x00007ffff6232f2b in osgUtil::RenderBin::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #9 0x00007ffff6233436 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #10 0x00007ffff6244c13 in osgUtil::RenderStage::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #11 0x00007ffff6232f2b in osgUtil::RenderBin::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #12 0x00007ffff624352a in osgUtil::RenderStage::drawInner(osg::RenderInfo&, osgUtil::RenderLeaf*&, bool&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #13 0x00007ffff624446e in osgUtil::RenderStage::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #14 0x00007ffff6253e4e in osgUtil::SceneView::draw() () from /opt/FlightGear/lib64/libosgUtil.so.100 #15 0x00007ffff5b02a14 in osgViewer::Renderer::draw() () from /opt/FlightGear/lib64/libosgViewer.so.100 #16 0x00007ffff5b03c2a in osgViewer::Renderer::operator()(osg::GraphicsContext*) () from /opt/FlightGear/lib64/libosgViewer.so.100 #17 0x00007ffff52698e1 in osg::GraphicsContext::runOperations() () from /opt/FlightGear/lib64/libosg.so.100 #18 0x00007ffff52740c9 in osg::RunOperations::operator()(osg::GraphicsContext*) () from /opt/FlightGear/lib64/libosg.so.100 #19 0x00007ffff5273a38 in osg::GraphicsOperation::operator()(osg::Object*) () from /opt/FlightGear/lib64/libosg.so.100 #20 0x00007ffff52dec8f in osg::OperationThread::run() () from /opt/FlightGear/lib64/libosg.so.100 #21 0x00007ffff527399e in osg::GraphicsThread::run() () from /opt/FlightGear/lib64/libosg.so.100 #22 0x00007ffff4c52bfc in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /opt/FlightGear/lib64/libOpenThreads.so.13 #23 0x00007ffff77260db in start_thread () from /lib64/libpthread.so.0 #24 0x00007ffff206090d in clone () from /lib64/libc.so.6 Is this a bug in Mesa or more probably in FlightGear?
Created attachment 92730 [details] [review] patch1
Created attachment 92731 [details] [review] patch2
This can be a case of the application passing an invalid pointer to glNormalPointer(), but it's also possible that it's an issue with display list compilation in mesa. Do the patches I attached to the bug report fix the problem?
I did 4 test runs today with the FlightGear version of the day I made the bug report. The first two runs I did with current Mesa and ended in segfaults in _save_VertexAttrib4fvARB. The other two were after applying your patches and were successful. Can your patches fix segfaults in _save_VertexAttrib4fvARB as well or just in _save_Normal3fv? If they fix both, I'll conduct more tests to see if the problem really is fixed. If not, I'll have to re-establish the base line, meaning I'll have to test until I can reproduce the _save_Normal3fv again. Please note that I haven't seen any segfaults with a more recent FlightGear version. There were a couple of commits that might have touched the code leading to the application problem. If it helps you confirming your suspisions, I could dig further to identify the exact commit. All in all things look quite well. Thanks for looking into this!
The first patch might fix segfaults in both functions. The second patch would only fix a segfault in _save_VertexAttrib4fvARB. I'm going to attach a third patch that fixes yet another problem with display lists that might affect FlightGear/openscenegraph.
Created attachment 93419 [details] [review] patch3 Note that this patch will not apply on the master branch.
Created attachment 94028 [details] [review] consolidated and rebased patches I ported your patches to current master and with them had a 90 minute flight without incidents while without them current FlightGear would currently crash within a minute. Thanks for the work!
I've been running your patches for two weeks now forward porting them to current git master. FlightGear has been perfectly stable with them. Unfortunatley I now get compilation errors and since I don't know the code base at all they are kind of hard to fix. See any chance you can commit them to master?
(In reply to comment #8) > I've been running your patches for two weeks now forward porting them to > current git master. FlightGear has been perfectly stable with them. > > Unfortunatley I now get compilation errors and since I don't know the code > base at all they are kind of hard to fix. See any chance you can commit them > to master? Yeah, I will rebase them and see about getting them into master. Thanks for testing!
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/483.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.