Xephyr crashed with SIGSEGV

Bug #635523 reported by Sebastian Heinlein on 2010-09-11
This bug affects 5 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
xorg-server (Ubuntu)

Bug Description

Calling Xephyr :1 -query localhost with a XDMCP enabled gdm server.

ProblemType: Crash
DistroRelease: Ubuntu 10.10
Package: xserver-xephyr 2:1.9.0-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic
Uname: Linux 2.6.35-20-generic i686
Architecture: i386
Date: Sat Sep 11 08:34:27 2010
Disassembly: => 0x2e6271: Cannot access memory at address 0x2e6271
ExecutablePath: /usr/bin/Xephyr
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha i386 (20100908)
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Bochs Bochs
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-20-generic root=UUID=7b55ca20-b8cc-4da3-a4dd-d284582b4bad ro quiet splash
ProcCmdline: Xephyr :1 -query localhost
 Segfault happened at: 0x2e6271: Cannot access memory at address 0x2e6271
 PC (0x002e6271) ok
 SP (0xbfcb081c) ok
 Reason could not be automatically determined.
Signal: 11
SourcePackage: xorg-server
 #0 0x002e6271 in ?? ()
 No symbol table info available.
 #1 0x00000000 in ?? ()
 No symbol table info available.
 ?? ()
 ?? ()
Title: Xephyr crashed with SIGSEGV
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
 (bluetooth-applet:13370): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed
 (polkit-gnome-authentication-agent-1:13374): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:13376): GConf-CRITICAL **: gconf_value_free: assertion `value != NULL' failed
dmi.bios.date: 01/01/2007
dmi.bios.vendor: Bochs
dmi.bios.version: Bochs
dmi.chassis.type: 1
dmi.chassis.vendor: Bochs
dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr:
dmi.product.name: Bochs
dmi.sys.vendor: Bochs
glxinfo: Error: [Errno 2] No such file or directory
 distro: Ubuntu
 codename: maverick
 architecture: i686
 kernel: 2.6.35-20-generic

Sebastian Heinlein (glatzor) wrote :

 pixman_fill_sse2 (bits=0xb7715000, stride=640, bpp=32, x=0, y=0,
 sse2_fill (imp=0x9088058, bits=0xb7715000, stride=640,
 _pixman_implementation_fill (imp=0x9088058,
 pixman_fill (bits=0xb7715000, stride=640, bpp=32, x=0, y=0,
 fbFill (pDrawable=0x9088460, pGC=0x90872b0, x=0, y=0,

Changed in xorg-server (Ubuntu):
importance: Undecided → Medium
tags: removed: need-i386-retrace
Bryce Harrington (bryce) on 2010-11-26
visibility: private → public
Michael Stone (michael-laptop) wrote :

This bug is really ticking me off because it completely breaks sugar-emulator. Therefore, in the interests of helping to get it fixed, here's a simplified test case, a better stack trace, a core dump, and materials for building a -dbg package for xserver-xephyr.

Michael Stone (michael-laptop) wrote :

The segfault occurs because Xephyr's attempt to bgfill its client-facing root window writes past the end of the window's image data buffer.

The write fails because Xephyr's hostx_screen_init() function is requesting an image data buffer which is too small.

The image data buffer is too small because the calculation of bytes_per_line conflicts with the calculation of the screen's bits-per-pixel.

Finally, Ajax supplied a patch six months ago that, when rebased, fixes the problem:


For the past year, distro bugtrackers have been receiving reports that Xephyr segfaults when it tries to map its client-facing root window:


The cause of the problem is that, on some 24bpp hosts, this computation:


yields a value for priv->bytes_per_line which is too small. priv->bytes_per_line is then used by Xephyr to create its host-side image data buffer (resulting in a buffer that is too small). Then, when Xephyr maps its root window, it segfaults by writing beyond the end of the too-small image data buffer while filling its root window in response to expose-event/damage processing.

As for fixes: ajax proposed one fix for this problem six months ago that seems to have gotten lost after an unanswered request for an amendment by keithp:


I tested this patch against Ubuntu's xserver-xorg_2:1.9.0-0ubuntu7 package (from Maverick) and can confirm that it fixed the segfault for me in that environment.

Changed in xorg-server:
status: Unknown → Confirmed
Changed in xorg-server:
importance: Unknown → Medium
Timo Aaltonen (tjaalton) on 2011-02-20
Changed in xorg-server (Ubuntu):
status: New → Triaged

Still seeing this bug in Ubuntu 11.04 (Natty, not Maverick).

The definition of the KdScreenInfo data structure changed between the time of the aforementioned patch and now, so the lines:


should be:


I believe Keith Packard wanted a more robust patch, with the settings being obtained from the underlying XImage. But my individual need is smaller, and Xephyr is segfaulting for me, so the patch is "good enough for me". I applied the patch (with the modifications I mentioned) and Xephyr is now launching properly.

Dennis Sheil (dennis-sheil) wrote :

Seeing this problem in Natty. Ajax's patch works for me, although needing the following modifications in Natty due to the KdScreenInfo data structure definition changing -


should be:


Xephyr would not launch for me, now it does.

Last time around, Keith Packard wanted a more robust patch to deal with this, so that seems to be the requirements for Xephyr. I don't think Ubuntu's criteria is as high for this, and we can probably have the package patched locally with Ajax's patch.

I think we should just remove Xephyr in 1.12 now that we have xf86-video-nested

On Sun, Sep 18, 2011 at 01:18:20 -0700, <email address hidden> wrote:

> --- Comment #2 from Jeremy Huddleston <email address hidden> 2011-09-18 01:18:18 PDT ---
> I think we should just remove Xephyr in 1.12 now that we have xf86-video-nested

That seems rather premature to me.

Why not? We've been talking about it for 3-4 years now. How long does something need to be unmaintained and bitrot before you decide to move on to its replacement?

Has xf86-video-nested been packaged and backported to the stable/LTS releases of the major distributions? If not I would agree that closing this issue is premature.

xf86-video-nested is not in the LTS distros, but neither is xserver-1.12.

I'm simply advocating that for 1.12 and onward, we should not advocate use of Xnest, Xvfb, Xfake, and Xephyr and instead advocate use of this alternative. This will allow us to not split our efforts across three products which do the exact same thing going forward.

If you want to officially deprecate it in 1.12 and remove it in 1.13, I'm happy with that as well.

Sebastian Heinlein, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xorg-server REPLACE-WITH-BUG-NUMBER

Please note, given you already have done this in a prior release, performing this on a release prior to Trusty would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:

Changed in xorg-server (Ubuntu):
importance: Medium → Low
status: Triaged → Incomplete

commit 97cf53cc2ad7ecfdd495133bad31d0ec7d939326
Author: Søren Sandmann Pedersen <email address hidden>
Date: Mon Oct 21 16:58:54 2013 -0400

    ephyr: hostx_screen_init(): Fix bits_per_pixel and bytes_per_line

    When the depth of the Xephyr server matches that of the host X server,
    Xephyr simply uses the buffer associated with the XImage as its
    framebuffer. In this case, it is correct to get the bits_per_pixel and
    bytes_per_line values returned from hostx_screen_init() from the XImage.

    However, when the depth doesn't match the host, Xephyr uses a private
    framebuffer that is periodically copied to the XImage. In this case,
    the returned values of bits_per_pixel and bytes_per_line should be
    those of the private framebuffer, not those of the XImage.

    Reviewed-by: Eric Anholt <email address hidden>
    Signed-off-by: Soren Sandmann <email address hidden>
    Reviewed-by: Adam Jackson <email address hidden>

Changed in xorg-server:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.