Xephyr crashed with SIGSEGV

Bug #635523 reported by Sebastian Heinlein
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xorg-server (Ubuntu)
Incomplete
Low
Unassigned

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 2.6.35.4
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
ProcEnviron:
 SHELL=/bin/bash
 LANG=de_DE.utf8
SegvAnalysis:
 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
Stacktrace:
 #0 0x002e6271 in ?? ()
 No symbol table info available.
 #1 0x00000000 in ?? ()
 No symbol table info available.
StacktraceTop:
 ?? ()
 ?? ()
Title: Xephyr crashed with SIGSEGV
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors:
 (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
system:
 distro: Ubuntu
 codename: maverick
 architecture: i686
 kernel: 2.6.35-20-generic

Revision history for this message
Sebastian Heinlein (glatzor) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 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,

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in xorg-server (Ubuntu):
importance: Undecided → Medium
tags: removed: need-i386-retrace
Bryce Harrington (bryce)
visibility: private → public
Revision history for this message
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.

Revision history for this message
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:

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

Revision history for this message
In , Michael Stone (michael-laptop) wrote :

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

  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/635523
  https://bugzilla.redhat.com/show_bug.cgi?id=518960
  https://qa.mandriva.com/show_bug.cgi?id=47928

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

  http://cgit.freedesktop.org/xorg/xserver/tree/hw/kdrive/ephyr/ephyr.c#n255

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:

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

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.

Revision history for this message
Michael Stone (michael-laptop) wrote :
Changed in xorg-server:
status: Unknown → Confirmed
Changed in xorg-server:
importance: Unknown → Medium
Timo Aaltonen (tjaalton)
Changed in xorg-server (Ubuntu):
status: New → Triaged
Revision history for this message
In , Dsheil (dsheil) wrote :

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:

screen->fb[0].depth
screen->fb[0].bitsPerPixel

should be:

screen->fb.depth
screen->fb.bitsPerPixel

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.

Revision history for this message
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 -

screen->fb[0].depth
screen->fb[0].bitsPerPixel

should be:

screen->fb.depth
screen->fb.bitsPerPixel

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.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

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

Revision history for this message
In , Julien Cristau (jcristau) wrote :

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.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

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?

Revision history for this message
In , David Ayers (ayers) wrote :

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.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

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

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

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.

Revision history for this message
penalvch (penalvch) wrote :

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:
https://wiki.ubuntu.com/ReportingBugs

Changed in xorg-server (Ubuntu):
importance: Medium → Low
status: Triaged → Incomplete
Revision history for this message
In , Ajax-a (ajax-a) wrote :

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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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