Bug 518960 - Xephyr crashes in 24bpp
Xephyr crashes in 24bpp
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
19
All Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Patch, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-24 07:15 EDT by Michal Nowak
Modified: 2013-05-24 16:20 EDT (History)
4 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.14.1-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-24 16:20:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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 18:50 EST, Michael Stone
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 32765 None None None Never

  None (edit)
Description Michal Nowak 2009-08-24 07:15:43 EDT
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 03:29:53 EDT
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 04:42:20 EDT
Umm, well, how do I make such a snapshot, when the process "immediately" exits?
Comment 3 Matěj Cepl 2009-11-05 12:14:22 EST
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 06:37:52 EST
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 07:27:17 EST
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 19:21:25 EDT
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 2010-12-31 20:50:39 EST
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 18:50:24 EST
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 15:51:18 EDT
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 02:45:36 EDT
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 13:48:06 EDT
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 16:20:02 EDT
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.