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}
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.
Umm, well, how do I make such a snapshot, when the process "immediately" exits?
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.]
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
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]
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.
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
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.
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
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
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).
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.