Bug 22822 - Server crash when using cairo with non-identity matrix
Summary: Server crash when using cairo with non-identity matrix
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-17 08:41 UTC by Joel Bosveld
Modified: 2009-07-21 05:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test case (2.40 KB, text/plain)
2009-07-17 08:41 UTC, Joel Bosveld
no flags Details
back trace (7.76 KB, text/plain)
2009-07-17 08:42 UTC, Joel Bosveld
no flags Details
patch (750 bytes, patch)
2009-07-17 08:42 UTC, Joel Bosveld
no flags Details | Splinter Review
Possible fix (5.98 KB, patch)
2009-07-17 08:55 UTC, Michel Dänzer
no flags Details | Splinter Review
modified testcase to demonstrate rendering problem (3.03 KB, text/plain)
2009-07-17 09:48 UTC, Joel Bosveld
no flags Details
screenshot (62.74 KB, image/png)
2009-07-17 09:49 UTC, Joel Bosveld
no flags Details
oops, wrong test.c last time... (2.78 KB, text/plain)
2009-07-17 09:50 UTC, Joel Bosveld
no flags Details
Alternative possible fix (762 bytes, patch)
2009-07-18 08:19 UTC, Michel Dänzer
no flags Details | Splinter Review

Description Joel Bosveld 2009-07-17 08:41:28 UTC
Created attachment 27792 [details]
test case

I have attached crash log, a small testcase, and a patch which prevents the crash (but doesn't fix the problem).

It seems to be because create_bits_picture (fbpict.c:320) is creating a pixman_image with an invalid memory address for 'bits' because pPix->devPrivate.ptr ("the raw pixel data") is NULL.

This seems to be an exa bug as I cannot reproduce with xaa, and exa should (afaiu) be setting devPrivate.ptr to something non-null.

This is happening with close to master xserver and slightly old radeon code (still from the dri2/kms branches - haven't had a chance to move to newer stuff yet, and this is working fine for now).
Comment 1 Joel Bosveld 2009-07-17 08:42:05 UTC
Created attachment 27793 [details]
back trace

Backtrace
Comment 2 Joel Bosveld 2009-07-17 08:42:48 UTC
Created attachment 27794 [details] [review]
patch
Comment 3 Michel Dänzer 2009-07-17 08:55:25 UTC
Created attachment 27796 [details] [review]
Possible fix

Does this patch fix it?
Comment 4 Joel Bosveld 2009-07-17 09:48:50 UTC
Created attachment 27797 [details]
modified testcase to demonstrate rendering problem

Yes, that fixes the crash (without my patch applied, obviously). Thanks.

However, my testcase (uploaded a slightly modified version) doesn't render as I would expect, which is probably a problem with my code, but just incase.

When run without any parameters (eg "./test") it will use XCreateSimple window to create a child of the root, with one parameter ("./test a") it will use XCreateWindow to create an rgba window. Call this window "w2"

It creates another rgba window ("w"), and tries to 'copy from' "w2" -> "w". The problem is, when "w2" is created with XCreateSimpleWindow (and therefore not rgba), nothing appears. When "w2" is an rgba window, it works, although not properly - as seen in screenshot, the small window (w2) is copied to the larger (w1), but there is a black border the width of the decoration that it is offset by.
Comment 5 Joel Bosveld 2009-07-17 09:49:37 UTC
Created attachment 27798 [details]
screenshot
Comment 6 Joel Bosveld 2009-07-17 09:50:33 UTC
Created attachment 27799 [details]
oops, wrong test.c last time...

Sorry for the extra noise.
Comment 7 Michel Dänzer 2009-07-18 08:19:14 UTC
Created attachment 27811 [details] [review]
Alternative possible fix

Can you try this patch instead of the other one? It's an attempt at a simpler solution.

(In reply to comment #4)
> When "w2" is an rgba window, it works, although not properly - as seen in
> screenshot, the small window (w2) is copied to the larger (w1), but there is a
> black border the width of the decoration that it is offset by.

That doesn't seem to be the case here, but it sounds like you may be using the wrong coordinate system. Anyway it's off topic for this bug report, please either file a separate one or bring it up on an appropriate mailing list.
Comment 8 Michel Dänzer 2009-07-19 16:28:07 UTC
Comment on attachment 27811 [details] [review]
Alternative possible fix

Unfortunately it turns out this doesn't work, as GetScratchGC() may return a pre-allocated GC.
Comment 9 Michel Dänzer 2009-07-21 05:39:49 UTC
Better fix pushed to Git.


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.