Bug 431147 - Compiz(*fc9*) Crashes X(*fc9*)
Compiz(*fc9*) Crashes X(*fc9*)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: compiz (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-31 20:19 EST by Arlinton Bourne
Modified: 2009-07-14 13:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:09:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg Log File (65.42 KB, text/plain)
2008-01-31 20:19 EST, Arlinton Bourne
no flags Details
Xorg.conf (2.22 KB, text/plain)
2008-02-01 11:09 EST, Arlinton Bourne
no flags Details
Core Dump (892.31 KB, application/octet-stream)
2008-02-08 23:17 EST, Arlinton Bourne
no flags Details
My X log (27.95 KB, text/plain)
2008-03-08 23:41 EST, Sachin Garg
no flags Details

  None (edit)
Description Arlinton Bourne 2008-01-31 20:19:02 EST
Description of problem:
Running rawhide with compiz-0.6.2-6.fc9.x86_64
It essentially crashes the X server
(xorg-x11-server-Xorg-1.4.99.1-0.19.20080107.fc9.x86_64) when it is initialized.

This has been happening for quite some time (a few versions). When was the last
time it worked? Fedora8

Attached should be my Xorg.0.log. The log has debugging enabled for the intel
driver just in case the issue is there. There are alot of tracebacks printing
out libglx.so. Also compiz doesn't crash (oddly enough) when the video card is
running in 16bit mode but everything is garbled and pretty much unusable.

~Arlinton
Comment 1 Arlinton Bourne 2008-01-31 20:19:02 EST
Created attachment 293675 [details]
Xorg Log File
Comment 2 Matěj Cepl 2008-02-01 07:45:52 EST
Could we get your /etc/X11/xorg.conf please as well? Also, would it be possible
to run Xorg without any /etc/X11/xorg.conf whatsoever? Could we get Xorg.0.log
file from such attempt as well, please?
Comment 3 Kristian Høgsberg 2008-02-01 11:02:37 EST
Also, please install the xserver debuginfo RPM and try to get a log file with a
stacktrace again.

thanks,
Kristian
Comment 4 Arlinton Bourne 2008-02-01 11:09:54 EST
Created attachment 293740 [details]
Xorg.conf
Comment 5 Arlinton Bourne 2008-02-08 23:17:08 EST
Created attachment 294448 [details]
Core Dump
Comment 6 Jan Lindblom 2008-02-26 03:16:49 EST
I have the same or similar problem with fc9 alpha and Intel GMA 950 integrated 
video on MSI 945GCM5-F V2 motherboard. Its quite easy to reproduce: start X, 
enable compiz (or possibly any other application using 3D accel), mode around 
some window to use 3D accel and after a short time the screen freezes, and then 
it goes black. After that the computer doesn't seem to respond to anything but 
the reset button.
Comment 7 Arlinton Bourne 2008-03-05 19:58:28 EST
Update:
Using the versions...
  xorg-x11-server-Xorg-1.4.99.900-0.28.20080304.fc9.x86_64
  xorg-x11-drv-i810-2.2.1-4.fc9.x86_64
  compiz-0.6.2-6.fc9.x86_64

Compiz no longer crashes the X server.
What it does do is loads then turns the screen black. I can see the cursor move
around and change accordingly (as I move it over the terminal I had open
previously). The screen remain black but the system does not freeze and is not
in a crashed state. I can move windows around (using keyboard shortcuts). Again
the screen is black and displays nothing but the cursor. 

Issuing a Ctrl+C into the terminal where I opened compiz, my screen returns (i
can see content and not just black) and I have no window manager.

Stay tuned for more...
Comment 8 Sachin Garg 2008-03-08 23:41:49 EST
Created attachment 297346 [details]
My X log

I have the same problem. My screen also turns black but with CTRL-C I am able
work fine again
Comment 9 Jarod Wilson 2008-04-01 10:20:47 EDT
Nb: this looks like possibly a dupe of 435969.

Running Xorg under gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff0ef829780 (LWP 7942)]
0x0000003b26a84f2b in memcpy () from /lib64/libc.so.6
(gdb) bt full
#0  0x0000003b26a84f2b in memcpy () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ff0df1a39e1 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d4de5ab0)
    at /usr/include/bits/string3.h:52
        i = 0
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#2  0x00007ff0df1a38c8 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d1aef9c0)
    at ../common/dri_bufmgr_fake.c:1006
        r = (struct fake_buffer_reloc *) 0x7ff0d0f35350
        i = 0
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#3  0x00007ff0df1a38c8 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d1af0400)
    at ../common/dri_bufmgr_fake.c:1006
        r = (struct fake_buffer_reloc *) 0x7ff0d0f75390
        i = 1
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#4  0x00007ff0df1a38c8 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d337cd70)
    at ../common/dri_bufmgr_fake.c:1006
        r = (struct fake_buffer_reloc *) 0x7ff0d1738300
        i = 161
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#5  0x00007ff0df1a3bb4 in dri_fake_process_relocs (batch_buf=0x7ff0d337cd70, 
    count_p=0x7ffff7854e44) at ../common/dri_bufmgr_fake.c:1045
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_process_relocs"
#6  0x00007ff0df1a4387 in _intel_batchbuffer_flush (batch=0x1e3acc0,
file=<value optimized out>, 
    line=<value optimized out>) at intel_batchbuffer.c:134
        intel = (struct intel_context *) 0x1af2830
        used = 3600
        was_locked = 0 '\0'
#7  0x00007ff0df1b8fb7 in intelTexImage (ctx=0x1af2830, dims=2, target=3553,
level=0, 
    internalFormat=6408, width=48, height=48, depth=1, border=0, format=32993,
type=5121, 
    pixels=0x7ff0d871e34c, unpack=0x1afed20, texObj=0x7ff0d354bdf0,
texImage=0x7ff0d354d590, 
    imageSize=0, compressed=0) at intel_tex_image.c:319
        intel = <value optimized out>
        intelImage = <value optimized out>
        postConvWidth = 48
        postConvHeight = 48
        texelBytes = <value optimized out>
        sizeInBytes = <value optimized out>
        dstRowStride = <value optimized out>
        srcRowStride = 48
        __FUNCTION__ = "intelTexImage"
        __PRETTY_FUNCTION__ = "intelTexImage"
#8  0x00007ff0df1b9f4d in intelTexImage2D (ctx=0x7ff0db1c2700, target=9216,
level=1152, 
    internalFormat=-128, width=0, height=<value optimized out>, border=0,
format=32993, type=5121, 
    pixels=0x7ff0d871e34c, unpack=0x1afed20, texObj=0x7ff0d354bdf0,
texImage=0x7ff0d354d590)
    at intel_tex_image.c:564
No locals.
#9  0x00007ff0df2484a6 in _mesa_TexImage2D (target=3553, level=0,
internalFormat=6408, width=48, 
    height=48, border=0, format=32993, type=5121, pixels=0x7ff0d871e34c) at
main/teximage.c:2564
        texObj = (struct gl_texture_object *) 0x7ff0d354bdf0
        texImage = (struct gl_texture_image *) 0x7ff0d354d590
        face = 0
        postConvWidth = 48
---Type <return> to continue, or q <return> to quit---
        postConvHeight = 48
        ctx = (GLcontext *) 0x7ff0db1c2700
#10 0x0000000000e24cd3 in __glXDisp_TexImage2D (pc=0x7ff0d871e318 "") at
indirect_dispatch.c:1153
No locals.
#11 0x0000000000e0ac0d in __glXDisp_RenderLarge (cl=0x1b26dd8,
pc=0x7ff0d01122a0 "")
    at glxcmds.c:1979
        client = (ClientPtr) 0x1b26c80
        dataBytes = 9216
        glxc = (__GLXcontext *) 0x1adf480
        error = <value optimized out>
        opcode = 110
        sw = <value optimized out>
#12 0x0000000000e0e9e2 in __glXDispatch (client=0x1b26c80) at glxext.c:492
        stuff = (xGLXSingleReq *) 0x7ff0d0112290
        opcode = <value optimized out>
        cl = (__GLXclientState *) 0x1b26dd8
        retval = 1
#13 0x00000000004462d4 in Dispatch () at dispatch.c:454
        clientReady = <value optimized out>
        result = <value optimized out>
        client = (ClientPtr) 0x1b26c80
        nready = 0
        start_tick = 46220
#14 0x000000000042c7bd in main (argc=8, argv=0x7ffff78552b8, envp=<value
optimized out>)
    at main.c:441
        i = 1
        error = 0
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}
Comment 10 Bug Zapper 2008-05-14 00:57:29 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Bug Zapper 2009-06-09 19:28:44 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2009-07-14 13:09:08 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.