Bug 13545 - [COMPIZ] compiz cause X crashed
Summary: [COMPIZ] compiz cause X crashed
Status: VERIFIED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Ext/DRI (show other bugs)
Version: git
Hardware: Other Linux (All)
: high major
Assignee: Default DRI bug account
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-06 01:22 UTC by Shuang He
Modified: 2008-01-30 17:43 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg conf (3.30 KB, text/plain)
2007-12-06 01:25 UTC, Shuang He
no flags Details
xorg log (21.00 KB, text/plain)
2007-12-06 01:27 UTC, Shuang He
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shuang He 2007-12-06 01:22:46 UTC
System Environment:
--------------------------

--Platform:gm965

--Architecture(32-bit,64-bit,compatiblity):64bit 

--2D driver: 75ef3e669dac1259d282dcc8f54b197fc19f22b3 

--Mesa: 3a90679400e50fb5d319deee51e03a298735aa17 

--DRM: 690dd04d1b9a4da92139793d3f5129a80f9c7353

--Xserver: aec0d06469a2fa7440fdd5ee03dc256a68704e77 


--Kernel:
2.6.23.1


Bug detailed description:
-------------------------
startx normally, then run compiz will cause X crashed, we get backtrace as following:

(gdb) bt
#0  0x0000003fbde305b5 in raise () from /lib64/libc.so.6
#1  0x0000003fbde32060 in abort () from /lib64/libc.so.6
#2  0x000000000045f633 in ddxGiveUp () at xf86Init.c:1290
#3  0x00000000004e5de8 in AbortServer () at log.c:406
#4  0x00000000004e63c5 in FatalError (
	f=0x55d3d0 "Caught signal %d.  Server aborting\n") at log.c:552
#5  0x0000000000476057 in xf86SigHandler (signo=11) at xf86Events.c:766
#6  <signal handler called>
#7  glxFillAlphaChannel (pixmap=<value optimized out>,
	x=<value optimized out>, y=0, width=<value optimized out>, height=25)
	at glxdri.c:322
#8  0x00002b1a2382694b in __glXDRIbindTexImage (
	baseContext=<value optimized out>, buffer=<value optimized out>,
	glxPixmap=0xb65900) at glxdri.c:439
#9  0x00002b1a237f54ac in __glXDisp_BindTexImageEXT (cl=<value optimized out>,
	pc=<value optimized out>) at glxcmds.c:1530
#10 0x00002b1a237f4282 in __glXDisp_VendorPrivate (cl=0xb55608,
	pc=<value optimized out>) at glxcmds.c:2245
#11 0x00002b1a237f8132 in __glXDispatch (client=0xb55410) at glxext.c:493
#12 0x0000000000447410 in Dispatch () at dispatch.c:502
#13 0x000000000042fa3a in main (argc=4, argv=0x7fff8834cbb8,
	envp=<value optimized out>) at main.c:454

Reproduce steps:
----------------
1. startx
2. run "compiz --replace"



Current result:
----------------
X crashed


Expected result:
----------------
compiz runs normally
Comment 1 Shuang He 2007-12-06 01:25:25 UTC
Created attachment 12974 [details]
xorg conf
Comment 2 Shuang He 2007-12-06 01:27:04 UTC
Created attachment 12975 [details]
xorg log
Comment 3 Michel Dänzer 2007-12-06 01:59:05 UTC
While this is triggered by EXA always hiding the pixmap data outside of Prepare/FinishAccess now, using pPixmap->devPrivate.ptr directly was never a very good idea. __glXDRIbindTexImage should be fixed to obtain the pixmap data with pScreen->GetImage and pass the result to glxFillAlphaChannel and glTex(Sub)Image2D. (Doing so might even make compiz usable with XAA without Option "XaaNoOffscreenPixmaps"...)

Any takers?


P.S. Implementing the DRI_TexOffset extension in the Mesa i965 driver should avoid this problem and improve performance with compiz.
Comment 4 Jesse Barnes 2007-12-06 12:23:52 UTC
Is this the same as 13507?
Comment 5 Shuang He 2007-12-06 16:59:18 UTC
(In reply to comment #4)
> Is this the same as 13507?
> 

No, I don't think so.
Comment 6 Eamon Walsh 2007-12-13 20:54:38 UTC
This is hitting me as well on current master.  Same stacktrace, confirm that pPixmap->devPrivate.ptr is zero going into glxFillAlphaChannel.  Can trigger the crash with glxgears.
Comment 8 Shuang He 2008-01-30 17:43:59 UTC
verified on 945GM and 915GV


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.