X server 1.5.2 aborts in __glxContextDestroy, within 15 minutes after login

[Jon Stumpf]

Kubuntu 8.10 on a Lenovo X40 laptop. Within 15 minutes after login, the X server crashes bringing me back to the login screen. The time to crash varies but doesn't exceed 15 minutes. I will include the information requested for Question #6617.

I am unable to reproduce the problem. It happens when the computer is in use and when it is idle. When I am using it, it seems to happen when I am using the trackpoint, scrolling up while using FireFox 3.x.

(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): tried to update DSPARB with both planes enabled!

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x79) [0x80c3009]
1: [0xb7f52400]
2: /usr/lib/xorg/modules/extensions//libglx.so(__glXContextDestroy+0x23) [0xb7a921d3]
3: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a9fade]
4: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x89) [0xb7a94859]
5: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a948a7]
6: /usr/bin/X(FreeResourceByType+0xe2) [0x8073c72]
7: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a90b77]
8: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a94c0a]
9: /usr/bin/X(Dispatch+0x34f) [0x808c89f]
10: /usr/bin/X(main+0x47d) [0x8071d1d]
11: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b55685]
12: /usr/bin/X [0x8071101]
Saw signal 11. Server aborting.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02)
     Subsystem: IBM Device [1014:055c]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
     Subsystem: IBM Device [1014:0557]

[Dan Trevino (dantrevino)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in xorg.

Please attach your X server configuration file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.0.log) to the bug report as individual uncompressed file attachments using the "Attachment:" box below. Could you please also try to run without any /etc/X11/xorg.conf and let Xorg autodetect your display and video card? Please also attach the /var/log/Xorg.0.log from this attempt. Thanks in advance.

[Jon Stumpf (jon-stumpf)]

Dan,

Thanks for getting back to me. The last crash was yesterday while it was idle. I have attached the information as you requested:

   xorg.conf
   Xorg.0.log (using the existing xorg.conf)
   Xorg.0.log (w/o xorg.conf)

- jss

[Jon Stumpf (jon-stumpf)]

Dan,

One additional point that may be related. During a session, I sometimes get a dialog box saying something to the effect that "a monitor configuration change has been detected" and it asks me if I would like to reconfigure or ignore. I have ignore and reconfigured - both with no obvious effect. Next time it happens, I will record the message. The last time happened during the session when the xorg.conf was not used.

- jss

[Bryce Harrington (bryce)]

Hi jon-stumpf,

Please attach the output of `lspci -vvnn` too.

[This is an automated message. If this script has reached you erroneously, please accept our apologies; any reply to this message will be sufficient to prevent it from doing further automated processing.]

[Bryce Harrington (bryce)]

Are you able to reproduce this issue on Jaunty? If so, please collect a full backtrace - see http://wiki.ubuntu.com/X/Backtracing for directions.

The logs show a pipe underrun but no backtrace is being printed out. Look in your /var/log/gdm/* files to see if an error message is getting printed out there. We need either a backtrace or an error message to know how to investigate this bug.

[Jon Stumpf (jon-stumpf)]

Note that I am using Kubuntu so I do not have a "/var/log/gdm" directory. That said, I have attached all the available "kdm" logs which have the "both planes enabled" error and a backtrace. Let me know if this is sufficient.

[Bryce Harrington (bryce)]

Thanks, that does help. What we really need though is a full backtrace. Since this is a hard to reproduce issue, that might be tough to get, but we've got the steps documented in detail at http://wiki.ubuntu.com/X/Backtracing - if you can get a full backtrace (with all symbols installed), it could help in identifying what the problem is.

[BastiG (bastig)]

I have a similar error on my acer notebook (intrepid, I'm not running jaunty yet). I have an ATI graphics card installed (Mobility Radeon 9700 I think) and I'm running the ati (radeon) driver. Therefore I don't get the exactly same Xorg log as stated before, but the backtrace is nearly equal (the memory locations are slightly different), but I think this could be the same issue. Additionaly I'm able to reproduce this error, because I experienced it while coding a small game with some of my fellow students. We use SDL in conjunction with OpenGL and I was able to produce a little program that raises the error when started. To compile use
$ g++ -g -gstabs -lGL -lGLU -lSDL crash.cpp
This is quite weird. The xserver crashes not all the times the program is called. There are at least 4 possibilites that I noticed:
  * the xserver crashes (see Xorg.0.log)
  * the executable crashes, showing a backtrace leading to munmap_chunk() (see backtrace.1)
  * the executable crashes, showing a backtrace leading to a "double free or corruption" (see backtrace.2)
  * the executable crashes printing a nice looking XServer error:

Starting test
Using software surface
Video mode set, calling SDL_Quit
X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 4 (X_DestroyWindow)
  Resource id in failed request: 0x380000f
  Serial number of failed request: 127
  Current serial number in output stream: 129

We're not that familiar with this SDL/OpenGL stuff, but the error (at least the xserver crash and the nice looking xserver error) is reproducable with the SDL-OpenGL-example by NeHe (http://nehe.gamedev.net), so I don't think we have such a big bug in our program.
So if this is a bug in conjunction with OpenGL (which is quite obvious, because of the libglx.so entires in the xserver-backtrace), Jon Stumpf is using compiz propably (I'm not)?
Unfortunately I cannot post a full backtrace, because I don't have a second machine available right now. If it is still needed, I could get one next week propably.

[Jon Stumpf (jon-stumpf)]

Bryce,

Following the Backtracing instructions, I added the debugger symbols and attempted to recreate the problem while Xorg was attached to gdb. I have been unsuccessful in duplicating the problem as of yet. The machine has not experienced the problem since it was rebooted: 21:23:08 up 2 days, 39 min.

What I have been able to do capture backtraces after Xorg receives SIGPIPE signals from what appears some failure between the screensaver and the Xorg server. The keuphoria.kss seems to hang after 30 seconds or so. I kill it with SIGHUP as SIGTERM does not work - I suspect by design.

I have attached 3 output files for your inspection. I will continue to attempt to recreate the problem. One difference (beyond the debugging symbols and gdb) is I didn't have the laptop in it's docking station. I will attempt that over the next couple of days.

- jss

- jss

[BastiG (bastig)]

I updated to jaunty today and I don't have my problem any more.

[Bryce Harrington (bryce)]

Thanks for letting us know the issue is resolved.