Xorg crashes in doListFontsAndAliases

Bug #794895 reported by Ivan Frederiks
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: xorg

Short way to reproduce:
Log in to "Recovery Console" session.
In terminal cd to directory with a git branch.
Run 'git citool' (git-gui package required).

Backtrace attached.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xorg 1:7.6+4ubuntu3.1
ProcVersionSignature: Ubuntu 2.6.38-10.44-generic-pae 2.6.38.7
Uname: Linux 2.6.38-10-generic-pae i686
NonfreeKernelModules: nvidia
.proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86 Kernel Module 270.41.19 Mon May 16 23:31:36 PDT 2011
 GCC version: gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
Architecture: i386
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
Date: Thu Jun 9 09:58:55 2011
DistUpgraded: Log time: 2011-05-02 09:42:28.404543
DistroCodename: natty
DistroVariant: ubuntu
DkmsStatus:
 nvidia-current, 270.41.19, 2.6.38-10-generic, i686: installed
 nvidia-current, 270.41.19, 2.6.38-10-generic-pae, i686: installed
 vboxhost, 4.0.8, 2.6.38-10-generic, i686: installed
 vboxhost, 4.0.8, 2.6.38-10-generic-pae, i686: installed
GraphicsCard:
 nVidia Corporation G86 [Quadro NVS 290] [10de:042f] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: nVidia Corporation Device [10de:0492]
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.2)
JockeyStatus:
 kmod:nvidia_current - nvidia_current (Proprietary, Enabled, Not in use)
 kmod:nvidia_173 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use)
MachineType: Hewlett-Packard HP Compaq 8000 Elite CMT PC
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-10-generic-pae root=UUID=0da0139d-a8bc-456d-9a4b-e1809439c5e7 ro quiet splash vt.handoff=7
Renderer: Unknown
SourcePackage: xorg
UpgradeStatus: Upgraded to natty on 2011-05-02 (37 days ago)
dmi.bios.date: 10/22/2009
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 786G7 v01.02
dmi.board.asset.tag: CZC044D3H7
dmi.board.name: 3647h
dmi.board.vendor: Hewlett-Packard
dmi.chassis.asset.tag: CZC044D3H7
dmi.chassis.type: 6
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr786G7v01.02:bd10/22/2009:svnHewlett-Packard:pnHPCompaq8000EliteCMTPC:pvr:rvnHewlett-Packard:rn3647h:rvr:cvnHewlett-Packard:ct6:cvr:
dmi.product.name: HP Compaq 8000 Elite CMT PC
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.4+bzr20110606-0ubuntu1~natty1
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.2-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental 7.10.2-0ubuntu2
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.2-0ubuntu2
version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu7.1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu7

Revision history for this message
In , Jon TURNEY (jon-turney) wrote :

Doing some investigation of this reported crash whilst using xserver 1.9.2 with xfs: http://cygwin.com/ml/cygwin-xfree/2010-11/msg00008.html, I'm able to reproduce this crash with the following sequence of actions:

X &
xterm &
xset fp+ tcp/myfontserver:7100
xlsfonts

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4712.0x1220]
0x005b2e29 in doListFontsAndAliases (client=0x125fdc0, c=0x120fce8) at dixfonts.c:611
611 fpe = c->fpe_list[c->current.current_fpe];
(gdb) p c
$1 = (LFclosurePtr) 0x120fce8
(gdb) p *c
$2 = {client = 0x120fce0, num_fpes = 18939104, fpe_list = 0x0, names = 0x0, current = {
    pattern = "▒W a\002\000\000\000ed-medium-r-normal--24-230-75-75-c-240-jisx0208.1983-0\va▒\207\va\000\000\000\000▒▒ \0019\017\000\000\b\000\000\000\000\000\000\000|▒%a\000\000\000\000\001\000\000\000\001\000\000\000▒\207\va\220▒\va@▒\va\000\000\000\000\030▒ \001\t\017\000\000\t\000\000\000\024\004\000\000▒▒%a\000\000\000\000\000\000\000\000\001\000\000\000\020\231\va▒\227\va▒\207\va\000\000\000\000H▒ \001▒\016\000\000\v\000\000\000\024\004\000\000▒▒%a\000\000\000\000\000\000\000\000\001\000\000\000"..., patlen = 62, current_fpe = 5, max_names = 3, list_started = 0, private = 0x12df550},
  saved = {
    pattern = "*\000\000\000\001\000\000\000\020\231\va▒\227\va▒\207\va\000\000\000\000▒&\001i\017\000\000\005\000\000\000\024\004\000\000|▒#a\000\000\000\000\000\000\000\000\001\000\000\000\020\231\va▒\227\va▒\207\va\000\000\000\000▒▒ \0019\017\000\000\b\000\000\000\000\000\000\000|▒%a\000\000\000\000\001\000\000\000\001\000\000\000▒\207\va\220▒\va@▒\va\000\000\000\000\030▒ \001\t\017\000\000\t\000\000\000\024\004\000\000▒▒%a\000\000\000\000\000\000\000\000\001\000\000\000\020\231\va▒\227\va▒\207\va\000\000\000\000H▒ \001▒\016\000\000\v\000\000\000\024\004\000\000▒▒%a\000\000\000\000\000\000\000\000\001\000\000\000"..., patlen = 1, current_fpe = 0, max_names = 65535, list_started = 1, private = 0x125fb10},
  haveSaved = 1, savedName = 0x12df338 "-jis-fixed-medium-r-normal--24-230-75-75-c-240-jisx0208.1983-0",
  savedNameLen = 64}
(gdb)

On further investigation, the reason for the closure c being corrupt seems to be related to the changes added in commit 3ab6cd31 to fix bug #3040.

In doListFontsAndAliases(), if we get a Suspended result when the client is already sleeping with the same closure (I don't really understand enough what the code is doing to know if that's expected or not), then the xinerama_sleep code frees() the closure c, so when it next wakes, the closure c is being used after being freed.

Being a use after free bug possibly explains why the original reporter is able to avoid the crash by changing the sequence of actions slightly.

The crash is not observed after reverting the noted commit, or with xserver 1.8.2

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

Created attachment 463801
abrt report from Xorg crash

Description of problem:
If you attempt to use the X font server (xorg-x11-xfs) on Fedora 14 with
the Fedora 14 X server, the X server will crash on many or any operation
that seems to involve inventorying fonts. The minimal set of packages over
a stock install necessary to do this seems to be xfs itself and the 100dpi
bitmapped fonts, but it's possible that other font types will also do this.
(I have not attempted to do an exhaustive inventory.)

Reverting back to the Fedora 13 X server (and dependent drivers) on a
Fedora 14 system avoids the crash. This crash happens with all versions
of the Fedora 14 X server that I have seen, both the one on the
distribution image, the initial update in the updates repository, and the
latest update.

This may be the same bug as #651197 and #648608. I am refiling because
I have somewhat different abrt traces and a minimal reproduction, but
please feel free to mark this bug as a duplicate of one of the others
as appropriate.

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

xorg-x11-xfs-1.0.5-8.fc14.x86_64
xorg-x11-fonts-100dpi-7.2-11.fc14.noarch
xorg-x11-server-Xorg-1.9.1-3.fc14.x86_64

How reproducible:
Completely

Steps to Reproduce:
1. install a stock 64-bit Fedora 14 system (may repro on i686; haven't tried)
2. install xorg-x11-utils (for xlsfonts), xorg-x11-xfs and xorg-x11-fonts-100dpi
3. start xfs with '/etc/rc.d/init.d/xfs start'
4. log in and add the xfs server to your font path:
       xset fp+ unix/:7100
5. run xlsfonts; the server will immediately crash

Actual results:

Server crash.

Expected results:

List of fonts.

Additional info:

The stock xfs configuration serves the same fonts that the X server
is already using, since both point to catalogue:/etc/X11/fontpath.d.
This has let me see that just having X with the bitmapped fonts or
just having X talk to xfs for fonts are not enough to create the crash.

The crash can also be reproduced with Xvfb:

Xvfb :1 -noreset &
DISPLAY=:1 xset fp+ unix/:7100
DISPLAY=:1 xlsfonts

Testing with Xvfb this way commonly shows a glibc error:
*** glibc detected *** Xvfb: double free or corruption (!prev): 0x0000000001d82210 ***

(the address varies)

I am attaching an abrt trace (from an Xorg crash, not Xvfb).

Revision history for this message
In , Jon TURNEY (jon-turney) wrote :
Revision history for this message
In , James Jones (cubanismo) wrote :

Created attachment 40973
Possible fix

Haven't tested this thoroughly, as I'm not convinced early-out is really the right way to handle Xinerama here, but I think this should fix the crashes at least. Feel free to try it out.

Revision history for this message
In , Colin-harrison (colin-harrison) wrote :

Hi,

It's not pretty, but James' patch fixes the crash for me.

Thanks,
Colin Harrison

Revision history for this message
In , Ian (ian-redhat-bugs) wrote :

After noticing that firefox startup and kde menus crashed my X server
every time, I can confirm this still happens with current FC14 Xorg:

$ rpm -q xorg-x11-xfs xorg-x11-fonts-100dpi xorg-x11-server-Xorg
xorg-x11-xfs-1.0.5-8.fc14.x86_64
xorg-x11-fonts-100dpi-7.2-12.fc14.noarch
xorg-x11-server-Xorg-1.9.3-4.fc14.x86_64

[ 2888.421] (II) config/udev: Adding input device HDA NVidia HP Out at Ext Front Jack (/dev/input/event7)
[ 2888.421] (II) No input driver/identifier specified (ignoring)
[ 2971.531]
Backtrace:
[ 2971.532] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x4a0488]
[ 2971.532] 1: /usr/bin/Xorg (0x400000+0x60d79) [0x460d79]
[ 2971.532] 2: /lib64/libc.so.6 (0x7fccea130000+0x33140) [0x7fccea163140]
[ 2971.532] 3: /usr/bin/Xorg (doListFontsWithInfo+0x1c1) [0x42e011]
[ 2971.532] 4: /usr/bin/Xorg (ProcessWorkQueue+0x21) [0x4318d1]
[ 2971.532] 5: /usr/bin/Xorg (WaitForSomething+0x5b) [0x459edb]
[ 2971.532] 6: /usr/bin/Xorg (0x400000+0x2d252) [0x42d252]
[ 2971.532] 7: /usr/bin/Xorg (0x400000+0x2152e) [0x42152e]
[ 2971.532] 8: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fccea14ee5d]
[ 2971.532] 9: /usr/bin/Xorg (0x400000+0x210d9) [0x4210d9]
[ 2971.532] Segmentation fault at address 0xd41a34b0
[ 2971.532]
Fatal server error:
[ 2971.532] Caught signal 11 (Segmentation fault). Server aborting

Also on an 32-bit machine, the original Xvfp test...

$ rpm -q xorg-x11-xfs xorg-x11-fonts-100dpi xorg-x11-server-Xorg
xorg-x11-xfs-1.0.5-8.fc14.i686
xorg-x11-fonts-100dpi-7.2-12.fc14.noarch
xorg-x11-server-Xorg-1.9.3-4.fc14.i686

$ Xvfb :1 -noreset &
[1] 27322
$ DISPLAY=:1 xset fp+ unix/:7100
$ DISPLAY=:1 xlsfonts

Backtrace:
0: Xvfb (xorg_backtrace+0x3c) [0x81badcc]
1: Xvfb (0x8047000+0x177226) [0x81be226]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0x1e440c]
3: Xvfb (0x8047000+0x1207bb) [0x81677bb]
4: Xvfb (ProcessWorkQueue+0x31) [0x816adc1]
5: Xvfb (WaitForSomething+0x57) [0x81b84c7]
6: Xvfb (0x8047000+0x11f31e) [0x816631e]
7: Xvfb (0x8047000+0x10d715) [0x8154715]
8: /lib/libc.so.6 (__libc_start_main+0xe6) [0x4cfe36]
9: Xvfb (0x8047000+0x15051) [0x805c051]
Segmentation fault at address 0x8

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

XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1.0"
      after 7 requests (7 known processed) with 0 events remaining.
$ [1]+ Exit 1 Xvfb :1 -noreset

After removing the fontserver from the fontpath, the crashes stopped.

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

*** Bug 31675 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

I have just tested, and this still happens on the just released X server
update to 1.9.5 (xorg-x11-server-Xorg-1.9.5-1.fc14).

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

James, have you sent this to xorg-devel for review / comment? I didn't see it in a quick check of emails from you in December.

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

*** Bug 36060 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Acelists (acelists) wrote :

*** Bug 34007 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Cyril Brulebois (kibi) wrote :

Here's another ping for this bad crasher. :)

Revision history for this message
Ivan Frederiks (idfred) wrote :
bugbot (bugbot)
affects: xorg (Ubuntu) → xorg-server (Ubuntu)
Ivan Frederiks (idfred)
description: updated
Revision history for this message
Ivan Frederiks (idfred) wrote :

Success story:
Looks like I first got bug #774978, then I switched to proprietary nVidia driver and got https://bugs.freedesktop.org/show_bug.cgi?id=31501 due to
> Section "Files"
> FontPath "unix/:7100"
> EndSection
in xorg.conf

After cleanup of xorg.conf and installation of xserver-xorg-input-synaptics patched against #774978 my system became usable.

Changed in xorg-server (Ubuntu):
status: New → Fix Committed
status: Fix Committed → Confirmed
Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Bryce Harrington (bryce) wrote :

Hi iFred, great news. So, if I understand correctly, your issues are now completely resolved? Can we close out this bug report?

Revision history for this message
Ivan Frederiks (idfred) wrote :

Well, strict answer is no, because there is only a workaround (not quite obvious to regular user) but there is no patch that actually fixes this bug.
On the other hand it seems, that people on freedesktop.org bugzilla actually treat this bug as won't-fix.
But preventing nVidia config tool (and maybe other tools) from writing FontPath "unix/:7100" to xorg.conf could also be threated as a "fix" for this bug.

Revision history for this message
Ivan Frederiks (idfred) wrote :

I also noticed, that there is untested patch for this bug: https://bugs.freedesktop.org/attachment.cgi?id=40973

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

I've sent it to xorg-devel. Please review and comment in that thread

Revision history for this message
In , James Jones (cubanismo) wrote :
Download full text (4.4 KiB)

Discussion regarding why my patch ("Possible fix"), and a proposed patch from Adam Jackson, aren't functionally correct from a long time ago:

< jamesjones> ajax: Did that patch I attached to the font loading crash bug look at all correct?
< ajax> oh man, i seriously just finished writing a patch for that
< ajax> if you beat me to it i'm going to feel very lame
< jamesjones> sorry
< jamesjones> I'm not at all sure it's correct.
< ajax> oh wow, i see what you did.
< jamesjones> It seems like the whole idea of bailing out if you need to sleep ruins the point of Xinerama looping
< ajax> yeah, i don't think that's right
< ajax> one second...
< jamesjones> but I was too lazy to dig deeper since that patch was enough to unblock my testing.
< ajax> jamesjones: give this one a try? http://fpaste.org/BqJf/raw/
< ajax> i'm a bit ill at how that whole thing works, honestly.
< jamesjones> Give me a second, rebuilding
< jamesjones> But yeah, it doesn't make sense to me.
< ajax> at any rate it fixes my testcase of xset fp+ unix/:7100 && xlsfonts
< jturney> heh, it removes code, so it must be right :)
< jamesjones> Hehe
< ajax> nothing like having a library where your app has to implement functions with particular names and signatures to work
< jamesjones> but why the looping, if it's OK to return Success when the operation isn't done on screen[n] where n>0?
< ajax> jamesjones: it's not quite that.
< ajax> most of the font ops don't have any screen state, so you only have to call them once.
< ajax> PolyText and ImageTexto sleep do have to hit every screen, so you want to make sure that they only bump the client's sleep count once if they d
< ajax> so the minimal thing would have been to only change the closures for {Poly,Image}Text to not keep a sleep count
< ajax> but if you're doing that you may as well do them all
< jamesjones> right, I figured it was something like that, but then 1) Why loop the others 2) Why is it OK to early-out in PolyText/ImageText? Does the looping get restarted somewhere I'm not seeing when the client wakes up?
< jamesjones> I suppose I should just load up xinerama and step through it
< ajax> the others aren't actually looped by xinerama
< ajax> (which i had missed the first time around, i just assumed they were)
< jamesjones> ah, k
< jamesjones> that makes more sense.
< ajax> the text rendering routines push themselves onto the work queue if they don't have a font they need because the font server hasn't gotten back to them
< ajax> check out the context around ClientSleep in doImageText, it's quite horrific
< ajax> the way they wake up is that the font server's fd selects readable, and the handler for that notices which request tat reply was for and pokes the client back into the work queue
< ajax> i think that's right anyway? i kind of want to not know.
< jamesjones> it sounds right if there's only one screen
< ajax> well, if there's multiple screens, you might run through the sleep pattern multiple times
< jamesjones> Yeah, but it looks like each screen would loop in and block, only sleeping once
< jamesjones> then when it woke up, only the first screen would be serviced.
< jamesjones> *loop in and detect the need to sleep ra...

Read more...

Revision history for this message
Bryce Harrington (bryce) wrote :

Hey idfred,

You filed this bug report against natty, but I see it's still open and
doesn't appear to have much activity recently. So, now that oneiric
is released and stable, this may be a good point for you to upgrade
and re-test if this issue is still present there.

If it's solved in the new release and you think it's worth backporting
the fix, please indicate that. Or if having the fix in the new release
is good enough, feel free to close out the bug (or let us know and we'll
close it.)

If it's not solved, leave the bug report open. I can't promise we'll
get to it (we get way more bugs filed than we can usually get to), but
your testing and feedback can help out if and when we do.

Changed in xorg-server (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Ivan Frederiks (idfred) wrote :

I'm sorry, but new Ubuntu release breaks my favorite instruments like gnome2 and aptitude, so I don't plan to upgrade in the near future. And I have nVidia GPU only inside work PC. Probably I'll find some time for a LiveCD test.

Update:
I started LiveCD session on VirtualBox machine, manually installed xfs and easily reproduced crash by creating /etc/X11/xorg.conf with following contents:
Section "Files"
    FontPath "unix/:7100"
EndSection

Here is reply from xorg-server:

Backtrace:
[ 1098.881] 0: /usr/bin/X (xorg_backtrace+0x37) [0x80a6707]
[ 1098.882] 1: /usr/bin/X (0x8048000+0x62b4a) [0x80aab4a]
[ 1098.882] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x44840c]
[ 1098.882] 3: /usr/bin/X (doListFontsWithInfo+0xf3) [0x8072af3]
[ 1098.882] 4: /usr/bin/X (ProcessWorkQueue+0x2d) [0x80764dd]
[ 1098.882] 5: /usr/bin/X (WaitForSomething+0x5a) [0x80a3e6a]
[ 1098.882] 6: /usr/bin/X (0x8048000+0x29ed2) [0x8071ed2]
[ 1098.882] 7: /usr/bin/X (0x8048000+0x1c70c) [0x806470c]
[ 1098.882] 8: /lib/i386-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x1ae113]
[ 1098.882] 9: /usr/bin/X (0x8048000+0x1ca21) [0x8064a21]
[ 1098.882] Segmentation fault at address (nil)

Bryce Harrington (bryce)
Changed in xorg-server (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
In , Julien Cristau (jcristau) wrote :

*** Bug 48900 has been marked as a duplicate of this bug. ***

Changed in xorg-server:
importance: Medium → Critical
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Revision history for this message
penalvch (penalvch) wrote :

Ivan Frederiks, 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: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Ivan Frederiks (idfred) wrote :

@Christopher M. Penalver
I can't find 'xfs' package in trusty. Is X Font Srever available in this release?

Changed in fedora:
importance: Unknown → Medium
status: Unknown → Won't Fix
Revision history for this message
penalvch (penalvch) wrote :

OR using EOL release, no response for years, and upstream fix released in 2016.

no longer affects: xorg-server (Ubuntu)
affects: fedora → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
importance: Medium → Undecided
status: Won't Fix → New
no longer affects: xorg-server (Ubuntu)
affects: xorg-server → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
importance: Critical → Undecided
status: Confirmed → New
status: New → Invalid
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.