Bug 518960 - Xephyr crashes in 24bpp
Summary: Xephyr crashes in 24bpp
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 19
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-24 11:15 UTC by Michal Nowak
Modified: 2018-04-11 08:04 UTC (History)
5 users (show)

Fixed In Version: xorg-x11-server-1.14.1-2.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-24 20:20:02 UTC


Attachments (Terms of Use)
kdrive-ephyr-Fix-crash-on-24bpp-host-framebuffer (based on a similar patch by ajax) (2.86 KB, patch)
2011-01-01 23:50 UTC, Michael Stone
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 32765 None None None Never

Description Michal Nowak 2009-08-24 11:15:43 UTC
Description of problem:

[newman@localhost ~]$ gnome-shell 
xauth:  creating new authority file /tmp/gnome-shell.QU62jk/database
Traceback (most recent call last):
  File "/usr/bin/gnome-shell", line 273, in <module>
    shell = start_xephyr()
  File "/usr/bin/gnome-shell", line 95, in start_xephyr
    subprocess.Popen(["xlogo", "-geometry", "-0-0"])
  File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.6/subprocess.py", line 1092, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
[newman@localhost ~]$ record: RECORD extension enabled at configure time.
record: This extension is known to be broken, disabling extension now..
record: http://bugs.freedesktop.org/show_bug.cgi?id=20500

Backtrace:
0: Xephyr (xorg_backtrace+0x28) [0x578af8]
1: Xephyr (0x400000+0x17c479) [0x57c479]
2: /lib64/libpthread.so.0 (0x7f0e43f29000+0xf4c0) [0x7f0e43f384c0]
3: /usr/lib64/libpixman-1.so.0 (0x7f0e44597000+0x44b96) [0x7f0e445dbb96]
4: /usr/lib64/libpixman-1.so.0 (0x7f0e44597000+0x44d2e) [0x7f0e445dbd2e]
5: /usr/lib64/libpixman-1.so.0 (pixman_fill+0x3d) [0x7f0e445c959d]
6: Xephyr (fbFill+0x2b6) [0x47de16]
7: Xephyr (fbPolyFillRect+0x1d2) [0x493f72]
8: Xephyr (0x400000+0x12b7ab) [0x52b7ab]
9: Xephyr (miPaintWindow+0x1aa) [0x4a12ba]
10: Xephyr (miWindowExposures+0xc8) [0x4a1658]
11: Xephyr (MapWindow+0x325) [0x4697b5]
12: Xephyr (0x400000+0x38250) [0x438250]
13: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f0e416f9b8d]
14: Xephyr (0x400000+0x1d2e9) [0x41d2e9]
Segmentation fault at address 0x7f0e3f4b0000

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

xterm Xt error: Can't open display: :12


Version-Release number of selected component (if applicable):

gnome-shell-2.27.0-4.x86_64
xorg-x11-server-Xephyr-1.6.99-39.20090820.fc12.x86_64

How reproducible:

always

Steps to Reproduce:
1. run gnome-shell
2. traceback
3. GNOME with gnome-panel was still running
4. When Xephyr started now...

[newman@localhost ~]$ Xephyr

Fatal server error:
Server is already active for display 0
	If this server is no longer running, remove /tmp/.X0-lock
	and start again.

...looks like Xephyr is running somehow.
  
Actual results:

traceback/segfault

Expected results:

no traceback, Xephyr running

Additional info:

LOG from ABRT follows:

Common information
======

architecture
-----
x86_64

kernel
-----
2.6.31-0.125.4.2.rc5.git2.fc12.x86_64

package
-----
xorg-x11-server-Xephyr-1.6.99-39.20090820.fc12


Additional information
======

How to reproduce
-----
1.
2.
3.


cmdline
-----
Xephyr :87 -auth /tmp/gnome-shell.6tWJeb/database -screen 1024x768 -host-cursor 

executable
-----
/usr/bin/Xephyr

reason
-----
Process was terminated by signal 6

release
-----
Fedora release 11.91 (Rawhide)



Big Text Files
======
backtrace
-----
[?1034hCore was generated by `Xephyr :87 -auth /tmp/gnome-shell.6tWJeb/database -screen 1024x768 -host-cursor'.
Program terminated with signal 6, Aborted.
#0  0x00007fbc5a6ff675 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

Thread 1 (Thread 2348):
#0  0x00007fbc5a6ff675 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        pid = <value optimized out>
        selftid = <value optimized out>
#1  0x00007fbc5a700e55 in abort () at abort.c:92
        act = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
          sa_mask = {__val = {4316624, 0, 140447001370856, 206, 4671382, 
              268435456, 0, 140446947683056, 140447001243648, 0, 4294967295, 
              0, 1, 8284320, 0, 0}}, sa_flags = 32, sa_restorer = 0}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x0000000000473e01 in AbortDDX () at kdrive.c:338
No locals.
#3  0x000000000058278d in AbortServer () at log.c:404
No locals.
#4  0x0000000000582e7e in FatalError (
    f=0x5a04c8 "Caught signal %d (%s). Server aborting\n") at log.c:529
        args = {{gp_offset = 24, fp_offset = 48, 
            overflow_arg_area = 0x7ffff5dcfae0, 
            reg_save_area = 0x7ffff5dcfa20}}
        beenhere = 1
#5  0x000000000057c4ce in OsSigHandler (signo=11, sip=0x7fbc584a1000, 
    unused=<value optimized out>) at osinit.c:156
No locals.
#6  <signal handler called>
No symbol table info available.
#7  _mm_store_si128 (__B=<value optimized out>, __P=<value optimized out>)
    at /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include/emmintrin.h:697
No locals.
#8  save_128_aligned (__B=<value optimized out>, __P=<value optimized out>)
    at pixman-sse2.c:400
No locals.
#9  pixman_fill_sse2 (__B=<value optimized out>, __P=<value optimized out>)
    at pixman-sse2.c:4011
        w = 3968
        d = 0x7fbc584a1000 "\177ELF\002\001\001"
        byte_width = 4096
        byte_line = 0x7fbc584a1000 "\177ELF\002\001\001"
        xmm_def = 0x0
#10 0x00007fbc5d5cd64e in sse2_fill (imp=<value optimized out>, 
    bits=<value optimized out>, stride=<value optimized out>, bpp=32, x=0, 
    y=0, width=1024, height=768, xor=0) at pixman-sse2.c:5757
No locals.
#11 0x00007fbc5d5b9f9d in pixman_fill (bits=<value optimized out>, 
    stride=<value optimized out>, bpp=<value optimized out>, 
    x=<value optimized out>, y=<value optimized out>, 
    width=<value optimized out>, height=768, xor=0) at pixman.c:256
No locals.
#12 0x000000000047de16 in fbFill (pDrawable=0x1766d90, pGC=0x1764670, 
    x=<value optimized out>, y=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>) at fbfill.c:48
        dst = <value optimized out>
        dstStride = <value optimized out>
        dstBpp = 32
        dstXoff = <value optimized out>
        dstYoff = <value optimized out>
        pPriv = 0x1764850
#13 0x0000000000493f72 in fbPolyFillRect (pDrawable=<value optimized out>, 
    pGC=<value optimized out>, nrect=<value optimized out>, 
    prect=<value optimized out>) at fbfillrect.c:77
        pClip = 0x1766de0
        pbox = <value optimized out>
        extentX1 = 0
        extentX2 = 1024
        extentY1 = 0
        extentY2 = 768
        fullX1 = 0
        fullX2 = 1024
        fullY1 = 0
        fullY2 = 768
        partX1 = <value optimized out>
        partX2 = <value optimized out>
        partY1 = <value optimized out>
        partY2 = <value optimized out>
        xorg = 0
        yorg = 0
#14 0x000000000052b7ab in damagePolyFillRect (pDrawable=0x1766d90, 
    pGC=0x1764670, nRects=1, pRects=0x176fe50) at damage.c:1404
        pGCPriv = 0x1764830
        oldFuncs = 0x7f47a0
#15 0x00000000004a12ba in miPaintWindow (pWin=<value optimized out>, 
    prgn=0x7ffff5dd0310, what=<value optimized out>) at miexpose.c:649
        pScreen = <value optimized out>
        gcval = {{val = 3, ptr = 0x3}, {val = 0, ptr = 0x0}, {val = 0, 
            ptr = 0x0}, {val = 24382512, ptr = 0x1740c30}, {val = 8477504, 
            ptr = 0x815b40}, {val = 7, ptr = 0x7}}
        gcmask = 261
        pGC = <value optimized out>
        pbox = 0x7ffff5dd0310
        prect = 0x176fe50
        numRects = 1481248768
        draw_x_off = 0
        draw_y_off = 0
        tile_x_off = <value optimized out>
        tile_y_off = <value optimized out>
        fill = <value optimized out>
        drawable = 0x1766d90
#16 0x00000000004a1658 in miWindowExposures (pWin=0x1766d90, 
    prgn=0x7ffff5dd0310, other_exposed=0x0) at miexpose.c:504
        expRec = {extents = {x1 = -10272, y1 = 129, x2 = 0, y2 = 0}, 
          data = 0x1e}
        exposures = 0x7ffff5dd0310
#17 0x00000000004697b5 in MapWindow (pWin=0x1766d90, 
    client=<value optimized out>) at window.c:2680
        temp = {extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}, data = 0x0}
        pScreen = 0x1740c30
        pParent = 0x0
        pLayerWin = <value optimized out>
#18 0x0000000000438250 in main (argc=7, argv=<value optimized out>, 
    envp=<value optimized out>) at main.c:254
        i = 1
        alwaysCheckForInput = {0, 1}

Comment 1 Søren Sandmann Pedersen 2009-08-28 07:29:53 UTC
This

>    d = 0x7fbc584a1000 "\177ELF\002\001\001"

seems to indicate that it's trying to do a solid fill in an ELF mapping, which is rather WTF ...

I'd be curious to see what /proc/maps looks like at the time of backtrace.

Comment 2 Michal Nowak 2009-08-28 08:42:20 UTC
Umm, well, how do I make such a snapshot, when the process "immediately" exits?

Comment 3 Matěj Cepl 2009-11-05 17:14:22 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 4 Bug Zapper 2009-11-16 11:37:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Matěj Cepl 2010-02-26 12:27:17 UTC
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

Comment 6 Matěj Cepl 2010-05-10 23:21:25 UTC
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as INSUFFICIENT_DATA.

Comment 7 Michael Stone 2011-01-01 01:50:39 UTC
Matej,

I can reproduce the problem by running 'Xephyr -ac :1' on an F14 kvm guest that I use for testing. I encountered the problem when I recently resumed testing on Fedora because it breaks features in two packages that I care about; namely, sugar and rainbow. Finally, it turns out that ajax wrote a patch that fixes the problem six months ago:

  http://patchwork.freedesktop.org/patch/1327/

Therefore, can we please reopen this and get it fixed?

Thanks,

Michael

Comment 8 Michael Stone 2011-01-01 23:50:24 UTC
Created attachment 471357 [details]
kdrive-ephyr-Fix-crash-on-24bpp-host-framebuffer (based on a similar patch by ajax)

Here's a patch (which is a tweaked version of ajax's http://patchwork.freedesktop.org/patch/1327) which fixes the problem for me.

Comment 10 Fedora End Of Life 2013-04-03 19:51:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 11 Fedora Update System 2013-05-14 06:45:36 UTC
xorg-x11-server-1.14.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.1-2.fc19

Comment 12 Fedora Update System 2013-05-14 17:48:06 UTC
Package xorg-x11-server-1.14.1-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.14.1-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8173/xorg-x11-server-1.14.1-2.fc19
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2013-05-24 20:20:02 UTC
xorg-x11-server-1.14.1-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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