When starting a development build of fgrun or fgfs (FlightGear) with current git-head of mesa on intel GM45, the application crashes in do_row (mipmap.c). The same version of mesa, FlightGear, and OpenSceneGraph works fine on a separate machine, suggesting that this is a problem with the i965 driver. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff05abaec in do_row (datatype=<value optimized out>, comps=<value optimized out>, srcWidth=<value optimized out>, srcRowA=0x0, srcRowB=0x200, dstWidth=<value optimized out>, dstRow=0x2f95c00) at main/mipmap.c:183 183 dst[i][0] = (rowA[j][0] + rowA[k][0] + rowB[j][0] + rowB[k][0]) >> 2; (gdb) bt #0 0x00007ffff05abaec in do_row (datatype=<value optimized out>, comps=<value optimized out>, srcWidth=<value optimized out>, srcRowA=0x0, srcRowB=0x200, dstWidth=<value optimized out>, dstRow=0x2f95c00) at main/mipmap.c:183 #1 0x00007ffff05ad277 in make_2d_mipmap (datatype=5121, comps=2, border=0, srcWidth=256, srcHeight=256, srcPtr=0x0, srcRowStride=256, dstWidth=128, dstHeight=128, dstPtr=0x2f95c00 "", dstRowStride=128) at main/mipmap.c:1192 #2 0x00007ffff05b1faf in _mesa_generate_mipmap (ctx=0x20441e0, target=3553, texObj=0x2f2b1a0) at main/mipmap.c:1825 #3 0x00007ffff0694323 in _mesa_meta_GenerateMipmap (ctx=0x20441e0, target=3553, texObj=0x2f2b1a0) at drivers/common/meta.c:2268 #4 0x00007ffff05e6ff2 in check_gen_mipmap (target=3553, level=0, internalFormat=34027, width=256, height=256, border=0, format=6410, type=5121, pixels=0x2af5b30) at main/teximage.c:2270 #5 _mesa_TexImage2D (target=3553, level=0, internalFormat=34027, width=256, height=256, border=0, format=6410, type=5121, pixels=0x2af5b30) at main/teximage.c:2544 #6 0x00007ffff5b63ed7 in osg::Texture::applyTexImage2D_load (this=0x2adec70, state=..., target=3553, image= 0x2a15210, inwidth=256, inheight=256, numMipmapLevels=1) at ../../../openscenegraph-9999/src/osg/Texture.cpp:1793 #7 0x00007ffff5b5798d in osg::Texture2D::apply (this=0x2adec70, state=...) at ../../../openscenegraph-9999/src/osg/Texture2D.cpp:260 #8 0x00007ffff5b3862c in osg::StateSet::compileGLObjects (this=0x2a10090, state=...) at ../../../openscenegraph-9999/src/osg/StateSet.cpp:1349 #9 0x00007ffff5ecf6b6 in (anonymous namespace)::GLObjectsVisitor::apply (this=0x7fffffffca40, stateset=...) at ../../../openscenegraph-9999/src/osgUtil/GLObjectsVisitor.cpp:112 #10 0x00007ffff5ecfba1 in (anonymous namespace)::GLObjectsVisitor::apply (this=0x7fffffffca40, node=...) at ../../../openscenegraph-9999/src/osgUtil/GLObjectsVisitor.cpp:49 #11 0x00007ffff5a6c9cc in osg::Geode::accept (this=0x295d710, nv=...) at ../../../openscenegraph-9999/include/osg/Geode:39 #12 0x00007ffff5aa8fc3 in osg::Group::traverse (this=0x2977fc0, nv=...) at ../../../openscenegraph-9999/src/osg/Group.cpp:62 #13 0x00007ffff5aaa3fc in osg::Group::accept (this=0x2977fc0, nv=...) at ../../../openscenegraph-9999/include/osg/Group:38 #14 0x00007ffff5aa8fc3 in osg::Group::traverse (this=0x2a55a30, nv=...) at ../../../openscenegraph-9999/src/osg/Group.cpp:62 #15 0x00007ffff5aaa3fc in osg::Group::accept (this=0x2a55a30, nv=...)
Does it also occur with LIBGL_ALWAYS_SOFTWARE=1 set in the environment? The backtrace looks like it would.
I can't reproduce the crash with LIBGL_ALWAYS_SOFTWARE set. I tried both the classic and the gallium software driver. Equally I can't reproduce the crash on a separate machine using the r300g driver. So far, only the i965 driver has exhibited the problem, and only if glsl shaders are in use by FlightGear. The system log shows (2.6.36.2 + tuxonice kernel): Dec 15 12:13:28 host kernel: fgfs[2126]: segfault at 0 ip 00007fc0712ff52c sp 00007fffea1fe660 error 4 in i965_dri.so[7fc071217000+389000] Dec 15 12:14:53 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 38 of 58, total 128757760 bytes, 0 fences: -28 Dec 15 12:14:53 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* 16496 objects [45 pinned], 895533056 object bytes [43507712 pinned], 43507712/234881024 gtt bytes Dec 15 12:14:53 host kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ. Dec 15 12:14:54 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 41 of 61, total 135114752 bytes, 0 fences: -28 Dec 15 12:14:54 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* 16666 objects [48 pinned], 807874560 object bytes [49864704 pinned], 49864704/234881024 gtt bytes Dec 15 12:14:54 host kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ. Dec 15 12:14:55 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 41 of 61, total 135114752 bytes, 0 fences: -28 Dec 15 12:14:55 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* 16566 objects [48 pinned], 806727680 object bytes [49864704 pinned], 49864704/234881024 gtt bytes Dec 15 12:14:55 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 38 of 58, total 128757760 bytes, 0 fences: -28 Dec 15 12:14:55 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* 16557 objects [45 pinned], 806424576 object bytes [43507712 pinned], 43507712/234881024 gtt bytes Dec 15 12:14:55 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 38 of 58, total 128757760 bytes, 0 fences: -28 Dec 15 12:14:55 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* 16647 objects [45 pinned], 807636992 object bytes [43507712 pinned], 43507712/234881024 gtt bytes Dec 15 12:14:56 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 41 of 61, total 135114752 bytes, 0 fences: -28 Dec 15 12:14:56 host kernel: [drm:i915_gem_do_execbuffer] *ERROR* 16638 objects [48 pinned], 828624896 object bytes [49864704 pinned], 49864704/234881024 gtt bytes
This seems to be hit a lot by WebGL in firefox, e.g. in https://mozillademos.org/demos/nocomply/demo.html See also https://bugzilla.mozilla.org/show_bug.cgi?id=612194 It has a simple testcase: https://bugzilla.mozilla.org/attachment.cgi?id=490499
As Benoit says, might be good to look at this, as Firefox will be exposing this functionality to more users fast (WebGL works with Linux Intel drivers on Firefox Nightly now, planned to go to release in the next months).
(In reply to comment #4) > As Benoit says, might be good to look at this, as Firefox will be exposing this > functionality to more users fast (WebGL works with Linux Intel drivers on > Firefox Nightly now, planned to go to release in the next months). The depth of your callstack looks different from the poster's, and it's hard to tell much since you don't have debug symbols, but it could easily be a different bug and a different bug with "webgl" mentioned would be likely to get more attention :)
This should be fixed as of: commit 10e418f3815d690b2526e835bc7eb421b6be7050 Author: Eric Anholt <eric@anholt.net> Date: Fri Jun 10 12:58:56 2011 -0700 mesa: Switch generate_mipmaps_compressed() to using TexImage2D to upload. The code was playing fast and loose with rowstrides, which meant that if a driver chose anything different for its alignment requirements, the generated mipmaps came out garbage. Unlike the uncompressed case, we can't generate mipmaps directly into image->Data, so by using TexImage2D we cut out most of the weird logic that existed to generate in-place into ->Data. The up/downside is that the driver recovery code for the fact that _mesa_generate_mipmaps whacked ->Data has to be turned off for compressed now. Fixes 6 piglit tests about compressed mipmap gen.
Is the fix part of Mesa 7.11 or a separate package? If separate package, does this package have a version number that appears in GL RENDERER/VERSION strings (I'm afraid no)? Do you confirm that the crash here was only a null pointer dereference, and not dereferencing other pointers? Trying to figure if there's a security issue with enabling WebGL by default on systems that have the bug.
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.