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
Reply to: