glxgears crashed with SIGSEGV due to no GLX on display :0

StacktraceTop:?? () from /usr/lib/libGL.so.1
?? () from /usr/lib/libGL.so.1
?? ()
?? () from /usr/lib/libGL.so.1
?? ()

Hi brian-murray,

Could you please collect a full backtrace from when this crash occurs? Directions on collecting full backtraces are at https://wiki.ubuntu.com/X/Backtracing

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

I'm not certain a full back trace would help out here. I'm less interested in this crash report than in apport not reporting these. I'd think a package hook for mesa similar to the usplash one could be written. Here's part of the usplash one:

if report.has_key('StacktraceTop'):
        top_fn = report['StacktraceTop'].splitlines()[0]
        if 'libx86.so' in top_fn or 'run_vm86' in top_fn:
            report['UnreportableReason'] = 'The crash happened in the firmware of \
the computer ("BIOS"), which cannot be influenced by the operating system.'

So I think checking the StactrackTop for libGL.so.1 and /var/log/Xorg.0.log for GLX not being enabled would be sufficient.

Okay, well the stacktrace is not analyzable but rather than closing the bug I'll bump it over to apport to look into improving support for this class of bug.

But should a program really crash if it relies on glx and it's not available? It should handle this condition more gracefully IMHO.

Bryce, what should apport do here? Is it safe to say that it should ignore _all_ crashes which end in libGL if 'extension "GLX" missing on display' occurs in /var/log/Xorg.0.log ?

Still waiting for an answer from Bryce to comment 7

pitti, yes these crashes can be ignored when GLX is missing. Certainly it's an issue that glxgears isn't checking for GLX, but this is an uncommon corner case, and glxgears is sort of just a test program anyway, so this isn't a priority to get fixed. We can just ignore these crashes.

OK, will add a check like in comment 7 to the ubuntu general hook.

I just tested this here by moving away libglx.so, and glxinfo does not crash any more, so I am closing the original bug.

I also determined that "extension "GLX" missing on display" is just written to stderr by Xlib, it does not appear in Xorg.0.log. Thus the apport hook can't grep for that. Instead, I'll grep for the absence of "Loading extension GLX".

trunk r1697

This bug was fixed in the package apport - 1.12-0ubuntu1

---------------
apport (1.12-0ubuntu1) lucid; urgency=low

  * New upstream release:
    - launchpad.py: Add options 'escalation_subscription' and 'escalation_tag'
      for handling bugs with more than 10 duplicates.
    - crashdb.conf: For Ubuntu, escalate bugs with >= 10 duplicates to
      "ubuntu-bugcontrol" and tag them with "bugpattern-needed".
      (LP: #487900)
    - general-hooks/generic.py: Filter out crashes on missing GLX
      (LP: #327673)
    - Add bash completion script. Thanks to Philip Muškovac. (LP: #218933)
    - launchpad.py: Drop APPORT_FILES whitelist for download() and instead
      just filter out file extensions that we know about (*.txt and *.gz).
      (LP: #444975)
    - launchpad.py: Do not put the Tags: field into the bug description, since
      they are already proper tags. In download(), convert the real tags back
      to the Tags: field. (LP: #505671)
    - test/crash: Update expected core dump flags for changed rlimit behaviour
      in Linux 2.6.32.
    - launchpad.py: Fix marking of 'checked for duplicate' for bugs with
      upstream tasks.
    - launchpad.py, get_fixed_version(): Do not consider a bug as invalid just
      because it has any invalid distro package task.
  * debian/local/setup-apport-retracer: Switch to lucid.
  * debian/local/setup-apport-retracer: Do not locally install python-apt and
    friends, users can run apt-get install in DC dchroots now.
  * debian/local/setup-apport-retracer: Don't add the retracer PPA for now,
    everything we need is in lucid.
 -- Martin Pitt <email address hidden> Wed, 20 Jan 2010 13:51:15 +0100