Bug 32803

Created attachment 41601 [details]
Crash captured in gdm log on radeon

This is the crash as I experience it on radeon.

Additional logs, including the ones from my nouveau crashes are still available in the Novell bug. I can upload them here if needed but I stole the disk out of the Nouveau machine to put into the radeon machine and the logs have rotated out.

Can you get a full gdb backtrace from the free() failure(s)? Though as you seem to get them all over the place, the problem might be memory corruption, in which case something like running the X server in valgrind might be in order.

Ok, sure. I've set up gdb to capture the full trace. I agree that it's not likely to be helpful. I'll get valgrind set up for the next time it crashes.

Created attachment 41623 [details]
Log from Xorg started with valgrind

Here's the log captured from Xorg starting up with valgrind. Unfortunately, it doesn't capture the problem because the screen was actually blank with no pointer. The log does indicate several issues that it caught while starting up:
==1206== Syscall param ioctl(generic) points to unaddressable byte(s)
==1206==    at 0x65DAA47: ioctl (syscall-template.S:82)
==1206==    by 0x514DBE: linuxMapPci (linuxPci.c:310)
==1206==    by 0x515262: xf86MapLegacyIO (linuxPci.c:447)
==1206==    by 0x46C91A: xf86ClaimPciSlot (xf86pciBus.c:275)
==1206==    by 0x46CB5E: xf86PciProbeDev (xf86pciBus.c:566)
==1206==    by 0x518423: xf86CallDriverProbe (xf86Bus.c:86)
==1206==    by 0x518CBE: xf86BusConfig (xf86Bus.c:130)
==1206==    by 0x46B0AB: InitOutput (xf86Init.c:507)
==1206==    by 0x4259AC: main (main.c:209)
==1206==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1206== ==1206== Syscall param ioctl(generic) points to uninitialised byte(s)
==1206==    at 0x65DAA47: ioctl (syscall-template.S:82)
==1206==    by 0x81FD917: drmIoctl (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x82010E4: drmModeGetCrtc (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x8CFAB49: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x8CF7771: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x46B1A1: InitOutput (xf86Init.c:540)
==1206==    by 0x4259AC: main (main.c:209)
==1206==  Address 0x7ff000760 is on thread 1's stack
==1206==    at 0x65DAA47: ioctl (syscall-template.S:82)
==1206==    by 0x81FD917: drmIoctl (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x82017E9: drmModeGetProperty (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x8CFAFD0: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x8CF7771: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x46B1A1: InitOutput (xf86Init.c:540)
==1206==    by 0x4259AC: main (main.c:209)
==1206==  Address 0x7ff000788 is on thread 1's stack
==1206== Syscall param ioctl(generic) points to uninitialised byte(s)
==1206==    at 0x65DAA47: ioctl (syscall-template.S:82)
==1206==    by 0x81FD917: drmIoctl (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x820133B: drmModeGetEncoder (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x8CFAC21: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x8CF7771: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x46B1A1: InitOutput (xf86Init.c:540)
==1206==    by 0x4259AC: main (main.c:209)
==1206==  Address 0x7ff0007b8 is on thread 1's stack

==1206== Syscall param ioctl(generic) points to uninitialised byte(s)
==1206==    at 0x65DAA47: ioctl (syscall-template.S:82)
==1206==    by 0x81FD917: drmIoctl (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x82017E9: drmModeGetProperty (in /usr/lib64/libdrm.so.2.4.0)
==1206==    by 0x8CF9E7F: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x4897E6: xf86ProbeOutputModes (xf86Crtc.c:1614)
==1206==    by 0x48B2C7: xf86InitialConfiguration (xf86Crtc.c:2369)
==1206==    by 0x8CFADD7: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x8CF7771: ??? (in /usr/lib64/xorg/modules/drivers/radeon_drv.so)
==1206==    by 0x46B1A1: InitOutput (xf86Init.c:540)
==1206==    by 0x4259AC: main (main.c:209)
==1206==  Address 0x7ff0003d8 is on thread 1's stack

(there are more in the log)

Created attachment 41624 [details]
GDB log during crash

(In reply to comment #4)
> Ok, sure. I've set up gdb to capture the full trace. I agree that it's not
> likely to be helpful.

Thanks, indeed. FWIW though it might be interesting to print *pPixmap and *pExaPixmap from the exaDestroyPixmap_mixed frame.


(In reply to comment #5)
> Here's the log captured from Xorg starting up with valgrind. Unfortunately, it
> doesn't capture the problem because the screen was actually blank with no
> pointer.

Beware that that's the X server's default startup behaviour these days... How exactly did you start the server and clients?

> The log does indicate several issues that it caught while starting up:

Valgrind's complaints related to ioctls are usually false positives, because it doesn't know exactly what the ioctls do. So I'm afraid we still don't have a smoking gun.

(gdb) print *pPixmap
$6 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 8 '\b', 
    bitsPerPixel = 8 '\b', id = 0, x = 0, y = 0, width = 1, height = 1, 
    pScreen = 0x81dd10, serialNumber = 177107}, devPrivates = 0xd67e00, 
  refcnt = 1, devKind = 4, devPrivate = {ptr = 0x0, val = 0, uval = 0, 
    fptr = 0}, screen_x = 0, screen_y = 0, usage_hint = 0}
(gdb) print *pExaPixmap
$7 = {area = 0x0, score = 0, use_gpu_copy = 0, sys_ptr = 0xd67c50 "", 
  sys_pitch = 4, fb_ptr = 0x0, fb_pitch = 256, fb_size = 0, accel_blocked = 0, 
  pDamage = 0xd67ea0, validSys = {extents = {x1 = 0, y1 = 0, x2 = 1, y2 = 1}, 
    data = 0x0}, validFB = {extents = {x1 = 0, y1 = 0, x2 = 1, y2 = 1}, 
    data = 0x0}, driverPriv = 0x0}

I also tried using valgrind with --sim-hints=lax-ioctls to get around the ioctl mess but it still didn't come up.

Created attachment 41674 [details] [review]
Pad size of system memory copy for 1x1 pixmaps

Would this patch happen to help?

(In reply to comment #9)
> Created an attachment (id=41674) [details]
> Pad size of system memory copy for 1x1 pixmaps
> 
> Would this patch happen to help?

Yep. That seems to have fixed it for me. I used to be able to cause the crash pretty reliably by closing firefox with a bunch of tabs open and that doesn't do it anymore.

Fix has landed in Git master and been nominated for the stable branches, thanks for the report and testing.