Bug 63784

Summary: X server crashes when resizing RGBA window (fbCopyNtoN)
Product: xorg Reporter: Daniel Scharrer <daniel>
Component: Server/Ext/CompositeAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED NOTOURBUG QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: siarhei.siamashka
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log for the crash
none
Detailed -O0 -ggdb crash backtrace with KWin window shadows/glow enabled
none
Detailed -O0 -ggdb crash backtrace with KWin window shadows/glow disabled none

Description Daniel Scharrer 2013-04-21 18:48:09 UTC
Created attachment 78308 [details]
Xorg.0.log for the crash

This crash happens with the AMD Catalys / fglrx driver installed, so it may well be a bug there (reported months ago as http://ati.cchtml.com/show_bug.cgi?id=657 but no response yet), however after my own poking i'm unsure if this is a bug in the driver or X.org server:

To reproduce:

1. Start KWin with compositing enabled (not sure if other WMs will do, but various bug reports suggest so)
2. Enabling "Window Drop-Down Shadows" and "Active Window Glow" (System Settings -> Workspace Appearance -> Window Decorations > Oxygen -> Configure Decoration -> Shadows) seems to increase the frequency of the crash but is *not* required.
3. Start a program with an RGBA window (such Konsole with transparency)
4. Drag a corner of the window and keep resizing - the X server will crash soon enough


Looking at the backtrace in gdb, I noticed that the crash happened in a pixman_blt call with a negative source offset, which it apparently doesn't handle correctly. pixman_blt is called by fbCopyNtoN, which is called from somehwhere in fglrx's glesx.so - but the negative offset comes from X.org server code much higher in the call stack.

This offset just so happened to coincide with the size of the "glow"/shadow effect KWin applies (active) windows. However, the crash still happens (but without the negative offset) when disabling that feature in KWin - but it feels like it happens less often.

From my reading of the backtraces and involved code it looks like X.Org allocates a pixmap for the new window size and then tries to fill in the new pixmap with the contents of the parent window (why this is done with compositing enabled is beyond me) but completely ignores the offset and dimensions of the parent window for the copy request.

This (seems to work) for non-RGBA windows as there is a special case if the source and destination bit depths match. The general case (which crashes here) was added for bug #7447 as a security fix.

Is GetPictureScreen(...)->Composite(...) supposed to check that the request is not out of bounds for the source / destination? I'm having trouble finding the documentation for these interfaces. Clearly the current fglrx implementation doesn't, but it used to work in earlier fglrx versions.

Here are the versions I tried:

 - xorg-server 1.12.4 + catalyst 12.8 => no crash
 - xorg-server 1.12.4 + catalyst 13.3 beta 3 (or anything > 12.8) => crash
 - xorg-server 1.13.4 + catalyst 13.3 beta 3 => crash
Comment 1 Daniel Scharrer 2013-04-21 18:48:48 UTC
Created attachment 78309 [details]
Detailed -O0 -ggdb crash backtrace with KWin window shadows/glow enabled
Comment 2 Daniel Scharrer 2013-04-21 18:49:07 UTC
Created attachment 78310 [details]
Detailed -O0 -ggdb crash backtrace with KWin window shadows/glow disabled
Comment 3 Daniel Scharrer 2014-12-13 10:47:35 UTC
Completely forgot that I posted this here :o

This was fixed in the amd catalyst driver a while ago.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.