Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine

StacktraceTop:
 memcpy (__len=3, __src=0x7fa49158eee4, __dest=0x7fa490152ed4) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
 cirRefreshArea (pScrn=<optimized out>, num=<optimized out>, pbox=0x7fff66a939a0) at ../../src/cir_shadow.c:36
 ShadowCopyArea (pSrc=0x7fa496d29c20, pDst=0x7fa496cc0740, pGC=0x7fa496c1a9a0, srcx=<optimized out>, srcy=<optimized out>, width=<optimized out>, height=1, dstx=0, dsty=0) at ../../../../hw/xfree86/shadowfb/shadow.c:618
 ProcCopyArea (client=0x7fa4965680f0) at ../../dix/dispatch.c:1622
 Dispatch () at ../../dix/dispatch.c:428

Status changed to 'Confirmed' because the bug affects multiple users.

Booting freshly installed quantal beta1 amd64 desktop under kvm (20120903.4)
As soon as I login, it kicks me back out to the graphical login. This was seen on the boot right after installation. If I manually reboot the system after that (i.e. shutdown kvm, properly start it back up without the -cdrom image specified), I am able to login.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1043513

The X crash happens when using the cirrus X driver. For KVM there is a new modeset driver in Quantal which should avoid this but there are currently races which cause that not to load properly (see bug #1038055). However the same problem hits Xen HVM guests and for those (and likely all real hw using that chip, if such still exist) it would be good to fix the cirrus X driver to work with the software emulated acceleration. Previously we would run unity2d and be ok.

Looks like 1048304 is another dupe of this?
1056511 looks like a very similar backtrace to me as well, even though the driver at the last stage is nouveau rather than cirrus, the rest of it looks the same.

As of todays Quantal update it's stable enough to allow me to login and get a few minutes of useage before failing.

Dave

Things also became better with the Cirrus driver and VMs. After being able to login I noticed that my KVM VM (which runs on a rather power efficient, iow not too fast, machine) still has occasional crashes of this type. And there you can see (and have to wait) every graphical "goodness" like fading in and out or docking. While the host I run the Xen VM (which uses the same cirrus emulation) runs rather smoothly (because it has more CPU power) and I think I did not see any crash, yet.
That somehow leads me to believe this could be a problem (in the cirrus case) of the communication between X driver, llvm-pipe and the emulated card being overrun in some way.
Not sure how this relates to the nouveau case. I would not think the X driver could be too fast for the 3D pipe in hardware. But maybe this gives X driver people a hint.

Timo: As mentioned in #10 It's worth checking that bug 1056511 as well which is nouveau based, the backtrace looks similar enough to me to make me wonder if it's not driver specific.

Bug 1056511 has a proposed fix posted to it; if you suspect this might be a dupe of that bug then it would be worthwhile to test that patch.

Bug 1053702 (and bug 1045845) is another recent cirrus crash that was fixed about a month ago. If you've not reproduced the crash in October it is possible that was the cause of the problems.

In either case, please set this as a dupe accordingly. If the crash still occurs with latest quantal please post a fresh backtrace - see http://wiki.ubuntu.com/X/Backtracing for guidance.

Hi Bryce,
  See backtrace attached; just generated, on an up to date Quantal:

ii xserver-xorg-video-cirrus 1:1.5.1-0ubuntu2 amd64 X.Org X server -- Cirrus display driver

Looks the same one to me; it's a lot harder to hit this than it was a few weeks ago - this survived an hour of web browsing (mostly lp traiging) last night, but managed to trigger in a few minutes this morning - so it's rather difficult to know when we actually kill this bug. (kvm guest on quantal host)

Dave

actually, I seem to have found a reasonably repeatable sequence:
  1) Login
  2) open a gnome-terminal
  3) Walk through the 4 workspaces with ctrl-alt-arrows, within 2 or 3 times of doing that reasonably quickly it blows up.

Some more diags;

(gdb) p *pbox
$2 = {x1 = -958, y1 = -716, x2 = -236, y2 = -282}

I'm not sure what the space these values are working is supposed to be; if they're supposed to be -ve then they're in a sensible
range as far as I can tell - but are they supposed to be -ve?

(gdb) p pPriv->pScrn->virtualX
$7 = 1024
(gdb) p pPriv->pScrn->virtualY
$8 = 768

OK - seems right

(gdb) p src
$33 = (unsigned char *) 0x7f0a78505cd6 ""

7f0a784e0000-7f0a78506000 r-xp 00000000 fd:01 660179 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f0a78506000-7f0a78706000 ---p 00026000 fd:01 660179 /lib/x86_64-linux-gnu/libexpat.so.1.6.0

(gdb) p/x width
$37 = 0x876
(gdb) p/x src+width
$38 = 0x7f0a7850654c

Well that's why it's crashed - the src pointer is in the middle of expat and ends up running into the unreadable bit

(gdb) p dst
$34 = (unsigned char *) 0x7f0a770c8cc6 ""
Map entry: 7f0a76feb000-7f0a772cc000 rw-p 00000000 00:00 0

(gdb) p/x pCir->ShadowPtr
$30 = 0x7f0a78709010
(gdb) p/x pCir->FbBase
$31 = 0x7f0a772cc000
(gdb) p pCir->ShadowPtr-src
$24 = 2110266
(gdb) p pCir->FbBase-dst
$25 = 2110266
(gdb) p FBPitch
$26 = 3072

2110266/3072
686.9355468750

(P.S. as per previous instructions, try working through the 4 workspaces both clockwise and anti-clockwise)

Some random extra debug (from a separate run):
(gdb) up
#3 0x00007f0485ef1af3 in ShadowCopyArea (pSrc=0x7f048ba948f0, pDst=0x7f048c4ca910, pGC=0x7f048c3def70,
    srcx=<optimised out>, srcy=<optimised out>, width=<optimised out>, height=434, dstx=0, dsty=0)
    at ../../../../hw/xfree86/shadowfb/shadow.c:618
618 ../../../../hw/xfree86/shadowfb/shadow.c: No such file or directory.

(gdb) p pDst
$1 = (DrawablePtr) 0x7f048c4ca910
(gdb) p *pDst
$2 = {type = 0 '\000', class = 1 '\001', depth = 32 ' ', bitsPerPixel = 32 ' ', id = 56623110, x = -958,
  y = -716, width = 722, height = 434, pScreen = 0x7f048b738810, serialNumber = 2538}
(gdb) p/x *pDst
$3 = {type = 0x0, class = 0x1, depth = 0x20, bitsPerPixel = 0x20, id = 0x3600006, x = 0xfc42, y = 0xfd34,
  width = 0x2d2, height = 0x1b2, pScreen = 0x7f048b738810, serialNumber = 0x9ea}
(gdb) p pGC
$4 = (GC *) 0x7f048c3def70
(gdb) p pGC->pCompositeClip
$5 = (RegionPtr) 0x7f048c4ca960
(gdb) p *pGC->pCompositeClip
$6 = {extents = {x1 = -958, y1 = -716, x2 = -236, y2 = -282}, data = 0x0}
(gdb) p *(WindowPtr)pDst
$7 = {drawable = {type = 0 '\000', class = 1 '\001', depth = 32 ' ', bitsPerPixel = 32 ' ', id = 56623110,
    x = -958, y = -716, width = 722, height = 434, pScreen = 0x7f048b738810, serialNumber = 2538},
  devPrivates = 0x7f048c4ca9e0, parent = 0x7f048c4c9b80, nextSib = 0x0, prevSib = 0x0,
  firstChild = 0x7f048c4cade0, lastChild = 0x7f048c4cade0, clipList = {extents = {x1 = -958, y1 = -716,
      x2 = -236, y2 = -282}, data = 0x0}, borderClip = {extents = {x1 = -958, y1 = -716, x2 = -236,
      y2 = -282}, data = 0x0}, valdata = 0x0, winSize = {extents = {x1 = -958, y1 = -716, x2 = -236,
      y2 = -282}, data = 0x0}, borderSize = {extents = {x1 = -958, y1 = -716, x2 = -236, y2 = -282},
    data = 0x0}, origin = {x = 0, y = 0}, borderWidth = 0, deliverableEvents = 32799, eventMask = 4423680,
  background = {pixmap = 0xfff2f1f0, pixel = 4294111728}, border = {pixmap = 0x0, pixel = 0},
  backStorage = 0x0, optional = 0x7f048c4caa20, backgroundState = 2, borderIsPixel = 1, cursorIsNone = 1,
  backingStore = 0, saveUnder = 0, DIXsaveUnder = 0, bitGravity = 1, winGravity = 1, overrideRedirect = 0,
  visibility = 0, mapped = 1, realized = 1, viewable = 1, dontPropagate = 0, forcedBS = 0, redirectDraw = 0,
  forcedBG = 0, damagedDescendants = 0, inhibitBGPaint = 0}

(Is the depth/bitsPerPixel correct? I thought this was running at 24bpp - maybe this is some intermediate).
Note how almost every x/y value there is -ve.

To simplify my instructions from comment #15:
  1) Open a terminal (sits in top left)
  2) Ctrl-alt-down arrow to move down one virtual deskop

It blows up at (2).

(pScrn->virtual X/y in cirRefreshArea is 1024/768)

Confirmed still happening in Raring (That's a raring guest with Quantal host) as of today's install.

Hi,
  Attached is a patch that seems to fix this; however it needs looking at by someone who understands the code; in particular I have some questions:

  1) Does this also need to go in cirRefreshArea8/16/24/32 ?
  2) Why is the generic one being called if there are those specialised ones anyway?
  3) Is there something that will clip a BoxRec rather than having to use my func?

This was tested on 1.5.1-0ubuntu2 on raring.

The attachment "Clip the range in cirRefreshArea" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

well since nobody was forthcoming I've taken a look. The reason those specialized exist is because they're used for rotations.

I think your patch is slightly overdesigned, could you try if this patch works for you?

I also fixed up the other rotated versions

Hi Maarten,
  That patch isn't happy; but I'm not sure why yet; I've attached three screen captures:
    1) The version with the ubuntu built package - which shows the strange crosshatching from bug 1080674
    2) myversion.png - the version with my patch, looks the same as (1) but doesn't crash when I move around my virtual desktops
    3) lankhostversion.png (sorry - I typo'd your name !) - the version with your patch applied to a clean 1:1.5.1-0ubuntu2 built on raring.

So erm; that's odd; your version is very broken somehow (and also doesn't update as I type properly I think).
(Although it does fix bug 1080674 which I couldn't complain about!)

I can't immediately see a problem in your code; maybe the specialised versions need the min/max/x/y swapping
  if pCir->rotate is set?

As for mine being over engineered, obviously there is some personal preference in there; but I was working on the basis if it
was needed in all 4 versions then a function was a better bet, and shortClip v MIN/MAX, I tend to prefer functions and anyway the compiler should do what it thinks is best; but as I say that's personal preference.
Dave

Hang on, scrap that analysis - I noticed the logs show it's not loading the rebuilt cirrus module with that change; It's now showing an EABI mismatch error. I'll get back to you.

Dave

and to compound things, the kernel driver is now working on raring, so I can't load this one to test it; let me get back to you next weekend.

Dave

You can disable the cirrus driver in raring by blacklisting it in /etc/modprobe.d/blacklist.conf or temporarily removing it from /lib/modules

Maarten:
  OK, it still crashes, and the reason is you're MIN/MAX aren't sufficient:

cirRefreshArea: pbox: (-958,52 / -236,486) clipped: (0,52 / -236,486) pScrn->vX/Y 1024,768 rotate=0

you need to use both MIN and MAX on each coordinate to cope with the box being completely off one side of the screen.

Still convinced my version is over-engineered?

Dave

ok I added a if (width <= 0 || height <= 0) continue; to cope with this, similar to other drivers. Can you retest?

Thanks Maarten, that looks good; I guess with cirrus module loaded it's probably not actually that important on a raring release; but it's good to fix anyway, and I'd say backport to Quantal.

should be fixed in xf86-video-cirrus 1.5.2 then. I just pushed this upstream, and will do a release to raring shortly.

This bug was fixed in the package xserver-xorg-video-cirrus - 1:1.5.2-0ubuntu1

---------------
xserver-xorg-video-cirrus (1:1.5.2-0ubuntu1) raring; urgency=low

  * Sync from unreleased debian git.
    - Upstream release fixes cirRefreshArea SEGV (LP: #1043513)
  * Drop fix-fallback.diff, upstreamed.
 -- Maarten Lankhorst <email address hidden> Tue, 08 Jan 2013 11:21:32 +0100

Thanks Maarten; that does seem to have nailed it in Raring; SRU for Quantal?

Can you reproduce this on precise too? Might be worth it to have it there as well..

Anyway if you can fill out the testcase part, I should be able to get it sru'd for quantal, and if that works maybe precise as well.

Maarten: Filled in test case stuff (what did you mean about eth2?)
                  I wonder if this should be marked security; we know it's scribbling over bits of the X server, that's running as root,
                  although I don't know how to control what is scribbled where

(I'll get precise tested soon; just as soon as I convince LVM to allocate the disk space...)

Precise won't get Unity 3D up (even with some forcing); so I'll say not repeatable.
[If as per previous question it's a security issue though that may need some more looking at]