Bug#857984: xserver-xorg: Segfault in fbBltOne via glamor and mi ultimately from doShmPutImage of 1bpp bitmap
Package: xserver-xorg
Version: 1:7.7+18
Severity: important
Dear Maintainer,
I can reliably reproduce the attached segfault backtrace with
$ pgmnoise 2040 4752 | pgmtopbm | xli stdin
and scrolling down in the presented window. Window manager doesn't matter.
Hopefully it's correct to file this bug against the main server because I
don't see any mention of intel driver specifics.
Thank you-
- Robert Jacobs
--8<--
#0 0x7fffee8e9eb4 in fbBltOne (src=0x55b96838, srcStride=, srcStride@entry=54, srcX=0, dst=0x577f6000, dstStride=192,
dstStride@entry=1920, dstX=,
dstBpp=32, width=55296, height=140, fgand=0, fgxor=0, bgand=0,
bgxor=16777215) at ../../../../fb/fbbltone.c:334
fbBits = 0x7fffee8f5550
srcEnd =
pixelsPerDst = 1
unitsPerSrc = 32
leftShift = 0
rightShift = 32
startmask = 0
endmask = 0
bits =
bitsLeft = 0
bitsRight =
left =
mask =
nDst = 1728
w = 1024
n =
nmiddle =
dstS = 0
copy =
transparent =
srcinc =
endNeedsLoad = 0
startbyte = 0
endbyte = 0
#1 0x7fffee8eb317 in fbCopy1toN
(pSrcDrawable=pSrcDrawable@entry=0x55b93940,
pDstDrawable=pDstDrawable@entry=0x567e3820, pGC=pGC@entry=0x5653a720,
pbox=pbox@entry=0x7fffe7d0, nbox=, nbox@entry=1, dx=0,
dy=-1749, reverse=0, upsidedown=0, bitplane=1, closure=0x0) at
../../../../fb/fbcopy.c:123
src = 0x55b93a50
srcStride = 54
srcBpp = 1
srcXoff = 0
srcYoff = 0
dst = 0x567e3930
dstStride = 1920
dstBpp = 32
dstXoff = 1
dstYoff = 391
#2 0x70f264c0 in glamor_copy_cpu_fbo (closure=0x0, bitplane=1,
upsidedown=0, reverse=0, dy=-1749, dx=, nbox=1,
box=0x7fffe7d0, gc=0x5653a720, dst=0x1,
src=0x55b93940) at ../../../../glamor/glamor_copy.c:243
src_pix =
src_stride = 1920
src_yoff = 391
screen =
src_bits = 0x567e3930
dst_xoff = 0
dst_pixmap = 0x56320380
src_bpp =
src_xoff = 1
dst_yoff = 0
#3 glamor_copy_gl (closure=0x0, bitplane=1, upsidedown=0, reverse=0, dy=-1749,
dx=, nbox=1, box=0x7fffe7d0, gc=0x5653a720, dst=0x1,
src=0x55b93940)
at ../../../../glamor/glamor_copy.c:651
src_pixmap =
dst_pixmap =
#4 glamor_copy (src=src@entry=0x55b93940, dst=dst@entry=0x567a9310,
gc=gc@entry=0x5653a720, box=box@entry=0x7fffe7d0, nbox=nbox@entry=1,
dx=, dy=-1749,
reverse=0, upsidedown=0, bitplane=1, closure=0x0) at
../../../../glamor/glamor_copy.c:678
nbox = 1
box = 0x7fffe7d0
closure = 0x0
reverse = 0
dx =
gc = 0x5653a720
src = 0x55b93940
bitplane = 1
upsidedown = 0
dy = -1749
dst = 0x567a9310
#5 0x556ede7c in miCopyRegion
(pSrcDrawable=pSrcDrawable@entry=0x55b93940,
pDstDrawable=pDstDrawable@entry=0x567a9310, pGC=pGC@entry=0x5653a720,
pDstRegion=pDstRegion@entry=0x7fffe7d0, dx=dx@entry=0,
dy=dy@entry=-1749, copyProc=0x70f25880 , bitPlane=1,
closure=0x0) at ../../../../mi/micopy.c:121
careful =
reverse =
upsidedown =
pbox = 0x7fffe7d0
pboxNew1 =
pboxNew2 = 0x0
pboxBase =
pboxNext =
pboxTmp =
#6 0x556ee436 in miDoCopy (pSrcDrawable=0x55b93940,
pDstDrawable=0x567a9310, pGC=0x5653a720, xIn=0, yIn=0, widthSrc=1728,
heightSrc=195, xOut=0, yOut=1749,
copyProc=0x70f25880 , bitPlane=1, closure=0x0) at
../../../../mi/micopy.c:296
prgnSrcClip = 0x0
freeSrcClip = 0
prgnExposed = 0x0
rgnDst = {extents = {x1 = 0, y1 = 1749, x2 = 1728, y2 = 1944}, data =
0x0}
dx = 0
dy = -1749
box_x1 =
box_y1 =
box_x2 =
box_y2 =
fastSrc =
fastDst =
fastExpose =
#7 0x70f265be in glamor_copy_plane (src=,
dst=, gc=, srcx=, srcy=, width=, height=195, dstx=1,
dsty=2140, bitplane=1) at ../../../../glamor/glamor_copy.c:700
No locals.
#8 0x556960f1 in damageCopyPlane (pSrc=0x55b93940,
pDst=0x567a9310, pGC=0x5653a720, srcx=0, srcy=,
width=1728, height=195, dstx=1, dsty=2140, bitPlane=1)
at ../../../../../miext/damage/damage.c:808
ret =
oldFuncs = 0x559a3ce0
#9 0x55646436 in doShmPutImage (
data=0x7fffede5e000
"\267mj\364K\022\227Y\253\332\250\226\224\231VZ\256\354\200>e8\316^V\016JJN\333<G\355b\321\245\254\356Eu3C\265\302V\\\034J\356\362\366F\252\252\272[b\202\255\224k\te7VeU\356u\335P\221\263\265\207\222\214\261\322S\252Z\032U\351IG\253\351Y\371kR\327h\333\225D\332z\314{\222
\021\227\222\226\177m\006\320#\030\024\265=\257\341j\337\344\326\256\270LN\271
Bug#857983: xserver-xorg: Segfault in fbBltOne via glamor and mi ultimately from doShmPutImage of 1bpp bitmap
Package: xserver-xorg Version: 1:7.7+18 Severity: important Dear Maintainer, I can reliably reproduce the attached segfault backtrace with $ pgmnoise 2040 4752 | pgmtopbm | xli stdin and scrolling down in the presented window. Window manager doesn't matter. Hopefully it's correct to file this bug against the main server because I don't see any mention of intel driver specifics. Thank you- - Robert Jacobs --8<-- [4219580.694] (EE) Backtrace: [4219580.694] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4a) [0x5570d41a] [4219580.694] (EE) 1: /usr/lib/xorg/Xorg (0x4000+0x1bd1c9) [0x557111c9] [4219580.694] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x759f2000+0x110c0) [0x75a030c0] [4219580.694] (EE) 3: /usr/lib/xorg/modules/libfb.so (fbBltOne+0x584) [0x7fffee8e9eb4] [4219580.694] (EE) 4: /usr/lib/xorg/modules/libfb.so (fbCopy1toN+0x247) [0x7fffee8eb317] [4219580.694] (EE) 5: /usr/lib/xorg/modules/libglamoregl.so (0x70f1b000+0xb4c0) [0x70f264c0] [4219580.694] (EE) 6: /usr/lib/xorg/Xorg (miCopyRegion+0x1ac) [0x556ede7c] [4219580.694] (EE) 7: /usr/lib/xorg/Xorg (miDoCopy+0x466) [0x556ee436] [4219580.695] (EE) 8: /usr/lib/xorg/modules/libglamoregl.so (0x70f1b000+0xb5be) [0x70f265be] [4219580.695] (EE) 9: /usr/lib/xorg/Xorg (0x4000+0x1420f1) [0x556960f1] [4219580.695] (EE) 10: /usr/lib/xorg/Xorg (0x4000+0xf2436) [0x55646436] [4219580.695] (EE) 11: /usr/lib/xorg/Xorg (0x4000+0xf3cf5) [0x55647c f5] [4219580.695] (EE) 12: /usr/lib/xorg/Xorg (0x4000+0x545e5) [0x555a85e5] [4219580.695] (EE) 13: /usr/lib/xorg/Xorg (0x4000+0x58568) [0x555ac568] [4219580.695] (EE) 14: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf1) [0x756742b1] [4219580.695] (EE) 15: /usr/lib/xorg/Xorg (_start+0x2a) [0x5559621a] [4219580.695] (EE) [4219580.695] (EE) Segmentation fault at address 0x577f6000 --8<-- (gdb) bt full #0 0x7fffee8e9eb4 in fbBltOne (src=0x55b96838, srcStride=, srcStride@entry=54, srcX=0, dst=0x577f6000, dstStride=192, dstStride@entry=1920, dstX=, dstBpp=32, width=55296, height=140, fgand=0, fgxor=0, bgand=0, bgxor=16777215) at ../../../../fb/fbbltone.c:334 fbBits = 0x7fffee8f5550 srcEnd = pixelsPerDst = 1 unitsPerSrc = 32 leftShift = 0 rightShift = 32 startmask = 0 endmask = 0 bits = bitsLeft = 0 bitsRight = left = mask = nDst = 1728 w = 1024 n = nmiddle = dstS = 0 copy = transparent = srcinc = endNeedsLoad = 0 startbyte = 0 endbyte = 0 #1 0x7fffee8eb317 in fbCopy1toN (pSrcDrawable=pSrcDrawable@entry=0x55b93940, pDstDrawable=pDstDrawable@entry=0x567e3820, pGC=pGC@entry=0x5653a720, pbox=pbox@entry=0x7fffe7d0, nbox=, nbox@entry=1, dx=0, dy=-1749, reverse=0, upsidedown=0, bitplane=1, closure=0x0) at ../../../../fb/fbcopy.c:123 src = 0x55b93a50 srcStride = 54 srcBpp = 1 srcXoff = 0 srcYoff = 0 dst = 0x567e3930 dstStride = 1920 dstBpp = 32 dstXoff = 1 dstYoff = 391 #2 0x70f264c0 in glamor_copy_cpu_fbo (closure=0x0, bitplane=1, upsidedown=0, reverse=0, dy=-1749, dx=, nbox=1, box=0x7fffe7d0, gc=0x5653a720, dst=0x1, src=0x55b93940) at ../../../../glamor/glamor_copy.c:243 src_pix = src_stride = 1920 src_yoff = 391 screen = src_bits = 0x567e3930 dst_xoff = 0 dst_pixmap = 0x56320380 src_bpp = src_xoff = 1 dst_yoff = 0 #3 glamor_copy_gl (closure=0x0, bitplane=1, upsidedown=0, reverse=0, dy=-1749, dx=, nbox=1, box=0x7fffe7d0, gc=0x5653a720, dst=0x1, src=0x55b93940) at ../../../../glamor/glamor_copy.c:651 src_pixmap = dst_pixmap = #4 glamor_copy (src=src@entry=0x55b93940, dst=dst@entry=0x567a9310, gc=gc@entry=0x5653a720, box=box@entry=0x7fffe7d0, nbox=nbox@entry=1, dx=, dy=-1749, reverse=0, upsidedown=0, bitplane=1, closure=0x0) at ../../../../glamor/glamor_copy.c:678 nbox = 1 box = 0x7fffe7d0 closure = 0x0 reverse = 0 dx = gc = 0x5653a720 src = 0x55b93940 bitplane = 1 upsidedown = 0 dy = -1749 dst = 0x567a9310 #5 0x556ede7c in miCopyRegion (pSrcDrawable=pSrcDrawable@entry=0x55b93940, pDstDrawable=pDstDrawable@entry=0x567a9310, pGC=pGC@entry=0x5653a720, pDstRegion=pDstRegion@entry=0x7fffe7d0, dx=dx@entry=0, dy=dy@entry=-1749, copyProc=0x70f25880 , bitPlane=1, closure=0x0) at ../../../../mi/micopy.c:121 careful = reverse = upsidedown = pbox = 0x7fffe7d0 pboxNew1 = pboxNew2
Bug#726002: xserver-xorg-video-mga: Dualheading using 1.6.2 segfaults
Tormod Volden writes: On Fri, Oct 18, 2013 at 1:34 AM, Robert Jacobs wrote: Tormod Volden writes: Mouse droppings, is this traces of the mouse pointer not being cleaned up? Did dual head at one point work for you without such droppings? In this case testing of older versions (of server and driver) can help to spot the regression. Anyway, dual head with mouse droppings is better than no dual head. Yeah, mouse droppings from the outline moves by ctwm, regardless of whether using EXA or nothing. Bad interactions between the line drawing X calls and whatever is being done for the mouse cursor on the second head. Doesn't happen with XAA or NoAccel on 1.5.0, something worse happens with EXA on 1.5.0 (but we don't care). Is that mga 1.5.0? So it is independent of the server? Oh, no, sorry, I was just using snapshot.debian.net to compare the entire xorg release as of mga 1.5.0 (core 1.12.4) being in the repository vs when mga 1.6.2 hit (core 1.14.3) Using NoAccel, ctwm, with mga 1.6.2 built against debian's xserver-xorg-core 1.12.4 does not cause mouse droppings on the second head. EXA in same context terminates with Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers/mga_drv.so: undefined symbol: XAACreateInfoRec which is just confusing. 1.5.0 doesn't build against debian's xserver-xorg-core 1.14.3 due to the XAA removal. So I guess the mouse droppings are actually the new core's fault? - Robert -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vxih6-0005qa...@eamp.org
Bug#726002: xserver-xorg-video-mga: Dualheading using 1.6.2 segfaults
Tormod Volden writes: And ideally Cyril's 02-* dualhead patch should go upstream, so review of that would be welcome too. I'm not certain what meets upstream's standards? It's sitting ineffectively at https://bugs.freedesktop.org/show_bug.cgi?id=18472 ; I assume the problem is there no real maintainer there to accept it. I know it's been getting plenty of in-the-field testing though. Getting this segfault fixed upstream probably requires getting 18472 commited first. Yes, I think the problem is the lack of a maintainer or someone who cares. There is no real upstream since no X.org people use this driver, can test it, or can justify spending time on it. IMO as long as it doesn't introduce regressions the patch should be applied. Personally I am not so inclined to apply it and to some degree implicitly accept the support burden and maintainership since I don't have the hardware the test, and not enough technical insight to be deal with it without testing. However if I can collect some Reviewed-by's and Tested-by's and someone stays around for testing I could do it. I'm happy to count as a Tested-by, and as far as I can tell the patch 02_tentatively_unbreak_dual_head.diff looks sane to me. I'm unfortunately not very familiar with the Xorg low-level internals to do any kind of comparison to any other (if any) more-nearly maintained legacy driver. What kind of testing is needed? Just simple HEAD doesn't have obvious regressions on my hardware? If so, I did test a very close variant to the patch that's in LP 1180986, and it mostly worked, but as I said, I got droppings on the second head. - Robert -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vwifj-0004oi...@eamp.org
Bug#726002: xserver-xorg-video-mga: Dualheading using 1.6.2 segfaults
Tormod Volden writes:
On Thu, Oct 17, 2013 at 9:43 AM, Robert Jacobs wrote:
What kind of testing is needed? Just simple HEAD doesn't have obvious
regressions on my hardware? If so, I did test a very close variant to
the patch that's in LP 1180986, and it mostly worked, but as I said, I
got droppings on the second head.
What would be nice, especially if we would consider a point release,
is to have it tested against the latest xserver.
Is that xserver-xorg-core in sid? Or do I need to pull HEAD from
cgit.fd.o ?
Mouse droppings, is this traces of the mouse pointer not being cleaned
up? Did dual head at one point work for you without such droppings? In
this case testing of older versions (of server and driver) can help to
spot the regression. Anyway, dual head with mouse droppings is better
than no dual head.
Yeah, mouse droppings from the outline moves by ctwm, regardless of
whether using EXA or nothing. Bad interactions between the line
drawing X calls and whatever is being done for the mouse cursor on the
second head.
Doesn't happen with XAA or NoAccel on 1.5.0, something worse happens
with EXA on 1.5.0 (but we don't care).
Also doesn't happen with WindowMaker's outline moves. But those look
fancier. (They're [255-pixel] rather than flat color)
What follows isn't even the same bug, I should prooobably open a new
one. It happens with upstream HEAD using EXA, without dualheading.
EXA causes segfaults under any non-trivial load, e.g. openbox trying
to draw its menu. Causes stack corruption in an memcpy call so I can't
figure out what's going on in gdb, but valgrind tracks it back to:
==6278== Invalid read of size 4
==6278==at 0x482D160: memcpy (mc_replace_strmem.c:878)
==6278==by 0x51AC4B2: mgaDownloadFromScreen (mga_exa.c:743)
==6278==by 0x51C2FF5: ??? (in /usr/lib/xorg/modules/libexa.so)
==6278==by 0x1000AF: ???
==6278== Address 0xac is not stack'd, malloc'd or (recently) free'd
==6278==
Using this to track it down in gdb finds that
Breakpoint 2, mgaDownloadFromScreen (pSrc=0xb6122008, x=0, y=0, w=176, h=16,
dst=0xb6122088 , dst_pitch=1024) at mga_exa.c:730
732 char *src = pSrc-devPrivate.ptr;
devPrivate here contains only 0s.
Well, ok, fine, I go and add a check to see if src is NULL here and if
so it returns FALSE, and now it seems to work fine.
Uh, you'll want a patch, here:
--- mga_exa.c~ 2013-10-17 15:28:53.082541399 -0700
+++ mga_exa.c 2013-10-17 15:28:53.082541399 -0700
@@ -730,6 +730,9 @@
PMGA(pSrc);
char *src = pSrc-devPrivate.ptr;
+
+if (src == NULL) return FALSE;
+
int src_pitch = exaGetPixmapPitch(pSrc);
int cpp = (pSrc-drawable.bitsPerPixel + 7) / 8;
---tear here---
I made an annotated version, it works correctly about 9% of the
time... is that bad? Do you have any ideas why the pSrc-devPrivate
structure would be {0,0,0,0} ?
Here's another random one:
Program received signal SIGSEGV, Segmentation fault.
0xb7a3a46c in mgaCheckComposite (op=3, pSrcPict=0x806d4b70,
pMaskPict=0x805ffd70,
pDstPict=0x806d4d98) at mga_exa.c:359
359 MGAPtr pMga =
xf86ScreenToScrn(pSrcPict-pDrawable-pScreen)-driverPrivate;
(gdb) p pSrcPict-pDrawable
$8 = (DrawablePtr) 0x0
I can be paranoid and add checks that it's never dereferencing NULL,
but that seems wrong. Surely that means something significant is
missing? Why would the acceleration methods be being passed what seems
to be garbage input?
- Robert
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vwx5x-0003vg...@eamp.org
Bug#726002: xserver-xorg-video-mga: Dualheading using 1.6.2 segfaults
Tormod Volden writes: On Fri, Oct 11, 2013 at 2:25 AM, Robert Jacobs wrote: The newest release of xorg removes xaa.h and xaalocal.h (and, indeed all of XAA). This means that the driver is built without defining HAVE_XAA_H, which in turn fails to compile the line in mga_storm.c:mgaAccelInit that ever fills the value of the function pointer RestoreAccelState. Finally, because this function pointer is null, in mga_driver.c:MGACrtc2FillStrip, it dereferences the null pointer and crashes. This reminds me that I have a patch for some of this sitting here: https://bugs.launchpad.net/bugs/1180986 Maybe you can take a look and possibly suggest a better patch. The right solution is for someone to modernize the 1.9.100 branch from six years ago, and give the MGA driver EXA support. But IIRC Brice Goglin had a number of problems that showed up in that branch. (e.g. debian 457502, 452223, 488762, 443936, 444739, c c c) When I tracked down this bug, I put in conditional execution that simply checked whether each function pointer was null and if so refused to dereference it. I feel like your conditional compilation patch is better, because then whenever upstream finishes ripping out XAA bits, the conditional compilation will be removed along with all the rest. And ideally Cyril's 02-* dualhead patch should go upstream, so review of that would be welcome too. I'm not certain what meets upstream's standards? It's sitting ineffectively at https://bugs.freedesktop.org/show_bug.cgi?id=18472 ; I assume the problem is there no real maintainer there to accept it. I know it's been getting plenty of in-the-field testing though. Getting this segfault fixed upstream probably requires getting 18472 commited first. - Robert Jacobs -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vwemd-0002qa...@eamp.org
Bug#640080: xvfb: Xvfb segfaults when a bit depth other than 8, 15, 16, 24, or 30 requested
This is fd.o bug 38420, they seem to have cleanly disabled nonstandard bitdepths: https://bugs.freedesktop.org/show_bug.cgi?id=38420 - Robert -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rijx4-00080x...@eamp.org
Bug#640080: xvfb: Xvfb segfaults when a bit depth other than 8, 15, 16, 24, or 30 requested
Package: xvfb
Version: 2:1.11.0-1
Severity: normal
If Xvfb is started with a bit depth of anything other than 8, 15, 16,
24, or 30, it segfaults.
This appears to be due to a missing case in
InitOutput.c:vfbScreenInit. At line 832 there's a switch
(pvfb-depth) and thus explicit support for only the aforementioned
display depths. When a bit depth other than the above is requested,
the micmap.c:miVisuals array is never filled with useful values and a
null pointer is dereferenced (micmap.c:miInitVisuals at the end where
it says depth[i].vids[j]).
I'd prefer some attempt to pick sane defaults when the user requests a
nonconventional bitdepth, but erroring out is definitely better than a
segfault.
Obviously this is not very important -- after all, no one seems to
have mentioned it before -- and the only mode I was actively thinking
about wanting was the 1bpp mode for testing. But since Xvfb is
mentioned as also being used for testing clients against unusual
depths, it would be nice to actually support said unusual depths.
Thank you!
- Robert Jacobs
p.s. Adding support for 1bpp seems to just involves adding:
case 1:
miSetVisualTypesAndMasks (1,
(1 StaticGray),
1, StaticGray, 0, 0, 0);
break;
I also have tested the following code for some sort of default for all
other depths, but it's rather ugly:
default:
if (pvfb-depth 8) {
int bluemask = (1 (pvfb-depth/3)) - 1;
int greenmask = ((1 ((2+pvfb-depth)/3)) - 1)
(pvfb-depth/3);
int redmask = ((1 pvfb-depth)-1) (~bluemask)
(~greenmask);
miSetVisualTypesAndMasks
(pvfb-depth,
((1 TrueColor) |
(1 DirectColor)),
(2+pvfb-depth)/38?(2+pvfb-depth)/3:8,
TrueColor, redmask, greenmask, bluemask);
} else if (pvfb-depth 8) {
miSetVisualTypesAndMasks (pvfb-depth,
((1 StaticGray) |
(1 GrayScale) |
(1 StaticColor) |
(1 PseudoColor) |
(1 TrueColor) |
(1 DirectColor)),
8, PseudoColor, 0, 0, 0);
}
break;
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xvfb depends on:
ii libaudit0 1.7.18-1
ii libc6 2.13-18
ii libgcrypt11 1.4.6-9
ii libpixman-1-0 0.22.2-1
ii libselinux1 2.1.0-1
ii libxau6 1:1.0.6-3
ii libxdmcp6 1:1.1.0-3
ii libxfont1 1:1.4.4-1
ii xserver-common 2:1.11.0-1
Versions of packages xvfb recommends:
ii xauth 1:1.0.6-1
xvfb suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qzjjy-0004cr...@eamp.org
