Red Hat Bugzilla – Bug 216042
GLcore double-free during visual cleanup
Last modified: 2007-11-30 17:07:37 EST
X just crashed during upgrading the system via yum from B2 to the current nightly build. Not sure if this is X, SELinux or something else. Let's start with X as that is what crashed... SELinux was in enforcing mode. 2006-11-16 15:28:50.000000000 -0500 /var/log/Xorg.0.log.old : Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80d4cc1] 1: [0xeb9420] 2: /lib/libc.so.6(cfree+0x4c) [0x4ecc650c] 3: /usr/lib/xorg/modules/extensions/libGLcore.so(_mesa_free+0x1d) [0xee244d] 4: /usr/lib/xorg/modules/extensions/libGLcore.so(XMesaDestroyVisual+0x1d) [0x104 0cdd] 5: /usr/lib/xorg/modules/extensions/libGLcore.so [0x1074e02] 6: /usr/lib/xorg/modules/extensions/libglx.so(__glXResetScreens+0x37) [0x1368c7] 7: /usr/lib/xorg/modules/extensions/libglx.so [0x135b0c] 8: /usr/bin/Xorg(CloseDownExtensions+0x46) [0x8095676] 9: /usr/bin/Xorg(main+0x49f) [0x806fa7f] 10: /lib/libc.so.6(__libc_start_main+0xdc) [0x4ec72f2c] 11: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e9) [0x806eda1] Fatal server error: Caught signal 11. Server aborting (**) RADEON(0): RADEONLeaveVT (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x8541ac8) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0xffff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x003fffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC2, offset: 0x40000000 (**) RADEON(0): Wrote: 0x00000000 0x00000000 0x00000000 (0x00006400) (**) RADEON(0): Wrote: rd=0, fd=0, pd=0 (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Ok, leaving now... /var/log/messages excerpt attached.
Created attachment 141420 [details] messages excerpt at time of X crash
I just had the same thing happen going from 1111.0 to 1116.0. Another interesting note is that it happens after the updates have been applied (that is, upon bringing X back up, yum had installed all of the packages I asked it to.)
Also meant to add that I'm running the vesa driver, so doesn't appear this is related to the ati driver at all.
Strange. The backtrace indicates that the server is on the shutdown path, ie, it's been asked to quit. That it then segfaulted from (what looks like) a double-free is merely a bonus. Looks like an X server bug, but I don't get why X was exiting in the first place.
So the rumor going around is that if gdm (or something related) gets updated, rpm will restart the service, which means the server exits. So there's two bugs here: one, we probably shouldn't trigger anything that'll restart X from %post, and two, the GLX visual list isn't getting cleaned up properly on server exit. Updating summary to reflect the latter. Jay, please handle cloning this bug for the gdm case (otherwise I'll show up as the reporter).
gdm %post does /usr/sbin/gdm-safe-restart which does not terminate the session for me.
Ah, should have put the same note here that I put in the cloned bug. gdm didn't change between the two trees I'm saw the problem in, so gdm isn't at fault, at least not it's %pre/%post scripts (as they weren't executed.) I'm going to try and reproduce the problem and see what happens.
Possibly a similar fix as done for #218395, although I don't think they're duplicates.
Turns out this was actually a dbus issue which has since been resolved. Marking as a duplicate of that bug (217721) *** This bug has been marked as a duplicate of 217721 ***