Bug 32096

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.