[smi] server crashes when a window is mapped while X is switching VTs

[Martijn vdS]

If a program tries to show a large windows while I'm switching back to X from
another VT, the X server tends to crash. This happened with both gdm
(ctrl+alt+f1 while you still see the black/white pattern, then alt+f7 while gdm
is done starting, for example)

You'll see a silhouette of the affected window, filled in the background color,
but somehow the X server crashes after that.

This means I can't close the lid on my laptop, as sometimes X crashes before
turning the monitor back on (and nothing can seem to turn it back on after
that), while sometimes it crashes with the silhouette of the "xscreensaver
password window" showing.

[Fabio Massimo Di Nitto (fabbione)]

Hi,
  can you try to reproduce this problem booting the laptop with the different
noacpi options turned on?

[Martijn vdS (martijn)]

It doesn't matter which ACPI/APIC options I use, but I've found it's much more
likely that X crashes if I touch the keyboard while X is switching into
graphical mode.

[Martijn vdS (martijn)]

I'm going to try to find some X.org binaries to see if the updates to the driver
that it has fix the problem.

[Martijn vdS (martijn)]

The bug still exists in Xorg 6.8.1

vendor string: The X.Org Foundation
vendor release number: 60801000

The easiest way to reproduce is to boot, wait for the black/white checkered
background (while gdmlogin is still starting), press Ctrl+Alt+F1, wait for the
beep gdm makes when you can login, and press Alt+F7. You don't even need to
press any other keys then.

Now let's see if I can get a trace...

[Martijn vdS (martijn)]

I've created this trace with xserver-xfree86-dbg, xlibs-dbg en libc6-dbg (and of
course gdb). It looks like it goes wrong with some "fbcopy" or something -- I'll
try again on 16-bits color:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0x400e64b3 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x400e7c08 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x08477b42 in ddxGiveUp () at xf86Init.c:1173
#4 0x08477c28 in AbortDDX () at xf86Init.c:1224
#5 0x0851a78a in AbortServer () at utils.c:436
#6 0x0851c1e6 in FatalError (
    f=0x8a46520 "Caught signal %d. Server aborting\n") at utils.c:1421
#7 0x08492fe0 in xf86SigHandler (signo=11) at xf86Events.c:1230
#8 <signal handler called>
#9 0x0853aba8 in fbBlt (srcLine=0x8ccfb98, srcStride=30, srcX=0,
    dstLine=0x40509dd4, dstStride=768, dstX=16, width=960, height=39, alu=3,
    pm=4294967295, bpp=24, reverse=0, upsidedown=0) at fbblt.c:272
#10 0x085448e8 in fbCopyNtoN (pSrcDrawable=0x8ccfad0, pDstDrawable=0x8bd95e0,
    pGC=0x8cc9ef0, pbox=0xbfffef30, nbox=0, dx=-498, dy=-373, reverse=0,
    upsidedown=0, bitplane=0, closure=0x0) at fbcopy.c:60
#11 0x085452ba in fbCopyRegion (pSrcDrawable=0x8ccfad0,
    pDstDrawable=0x8bd95e0, pGC=0x8cc9ef0, pDstRegion=0xbfffef30, dx=-498,
    dy=-373, copyProc=0x8544700 <fbCopyNtoN>, bitPlane=0, closure=0x0)
    at fbcopy.c:366
#12 0x08545721 in fbDoCopy (pSrcDrawable=0x8ccfad0, pDstDrawable=0x8bd95e0,
    pGC=0x8cc9ef0, xIn=0, yIn=0, widthSrc=40, heightSrc=40, xOut=498,
    yOut=373, copyProc=0x8544700 <fbCopyNtoN>, bitPlane=0, closure=0x0)
    at fbcopy.c:558
#13 0x08545861 in fbCopyArea (pSrcDrawable=0x8ccfad0, pDstDrawable=0x8bd95e0,
    pGC=0x8cc9ef0, xIn=0, yIn=0, widthSrc=40, heightSrc=40, xOut=498, yOut=373)
    at fbcopy.c:596
#14 0x0837e03b in XAACopyAreaFallback (pSrc=0x8ccfad0, pDst=0x8bd95e0,
    pGC=0x8cc9ef0, srcx=0, srcy=0, width=40, height=40, dstx=498, dsty=373)
    at xaaFallback.c:83
#15 0x0837fb33 in XAACopyArea (pSrcDrawable=0x8ccfad0, pDstDrawable=0x8bd95e0,
    pGC=0x8cc9ef0, srcx=0, srcy=0, width=40, height=40, dstx=498, dsty=373)
    at xaaCpyArea.c:70
#16 0x0864339d in miSpriteCopyArea (pSrc=0x8ccfad0, pDst=0x8bd95e0,
    pGC=0x8cc9ef0, srcx=0, srcy=0, w=40, h=40, dstx=498, dsty=373)
    at misprite.c:1190
#17 0x08637466 in miDCRestoreUnderCursor (pScreen=0x8b81098, x=498, y=373,
    w=40, h=40) at midispcur.c:536
#18 0x08646b6d in miSpriteRemoveCursor (pScreen=0x8b81098) at misprite.c:2256
#19 0x08642285 in miSpritePaintWindowBackground (pWin=0x8cee260,
    pRegion=0x8cf3d78, what=0) at misprite.c:842
#20 0x08623e86 in miWindowExposures (pWin=0x8cee260, prgn=0x8cf3d78,
    other_exposed=0x0) at miexpose.c:536
#21 0x084a2a2f in xf86XVWindowExposures (pWin=0x8cee260, reg1=0x8cf3d78,
    reg2=0x0) at xf86xv.c:1035
#22 0x0861ab62 in miHandleValidateExposures (pWin=0x8bd95e0) at miwindow.c:468
#23 0x0849574c in xf86SetRootClip (pScreen=0x8b81098, enable=1)
    at xf86Helper.c:1128
#24 0x08495828 in xf86EnableDisableFBAccess (scrnIndex=0, enable=1)
    at xf86Helper.c:1178
#25 0x08378de3 in XAAEnableDisableFBAccess (index=0, enable=1) at xaaInit.c:755
#26 0x08493463 in xf86VTSwitch () at xf86Events.c:1374
#27 0x08492eb...

[Martijn vdS (martijn)]

It doesn't work on 16 and 8-bit depth either.

[Fabio Massimo Di Nitto (fabbione)]

(In reply to comment #5)
> I've created this trace with xserver-xfree86-dbg, xlibs-dbg en libc6-dbg (and of
> course gdb). It looks like it goes wrong with some "fbcopy" or something -- I'll
> try again on 16-bits color:
>
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0x400e64b3 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2 0x400e7c08 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3 0x08477b42 in ddxGiveUp () at xf86Init.c:1173
> #4 0x08477c28 in AbortDDX () at xf86Init.c:1224
> #5 0x0851a78a in AbortServer () at utils.c:436
> #6 0x0851c1e6 in FatalError (
> f=0x8a46520 "Caught signal %d. Server aborting\n") at utils.c:1421
> #7 0x08492fe0 in xf86SigHandler (signo=11) at xf86Events.c:1230
> #8 <signal handler called>

This is interesting. Can you try deinstalling libc6-i686 and see if you can still
reproduce the bug?

What happens later is Xfree releasing it's resources and trying to do something
sane.

[Martijn vdS (martijn)]

Here's the backtrace of the X server, with libc6-i686 purged and libc6-dbg,
xlibs-dbg and xserver-xfree86-dbg installed:

(gdb) bt
#0 0x400e54d1 in raise () from /lib/tls/libc.so.6
#1 0x400e6bc5 in abort () from /lib/tls/libc.so.6
#2 0x08477b42 in ddxGiveUp () at xf86Init.c:1173
#3 0x08477c28 in AbortDDX () at xf86Init.c:1224
#4 0x0851a78a in AbortServer () at utils.c:436
#5 0x0851c1e6 in FatalError (
    f=0x8a46520 "Caught signal %d. Server aborting\n") at utils.c:1421
#6 0x08492fe0 in xf86SigHandler (signo=11) at xf86Events.c:1230
#7 <signal handler called>
#8 0x0853aba8 in fbBlt (srcLine=0x8ccfa30, srcStride=30, srcX=0,
    dstLine=0x40508dd4, dstStride=768, dstX=16, width=960, height=39, alu=3,
    pm=4294967295, bpp=24, reverse=0, upsidedown=0) at fbblt.c:272
#9 0x085448e8 in fbCopyNtoN (pSrcDrawable=0x8ccf968, pDstDrawable=0x8bd95a0,
    pGC=0x8cc9df0, pbox=0xbfffef30, nbox=0, dx=-498, dy=-373, reverse=0,
    upsidedown=0, bitplane=0, closure=0x0) at fbcopy.c:60
#10 0x085452ba in fbCopyRegion (pSrcDrawable=0x8ccf968,
    pDstDrawable=0x8bd95a0, pGC=0x8cc9df0, pDstRegion=0xbfffef30, dx=-498,
    dy=-373, copyProc=0x8544700 <fbCopyNtoN>, bitPlane=0, closure=0x0)
    at fbcopy.c:366
#11 0x08545721 in fbDoCopy (pSrcDrawable=0x8ccf968, pDstDrawable=0x8bd95a0,
    pGC=0x8cc9df0, xIn=0, yIn=0, widthSrc=40, heightSrc=40, xOut=498,
    yOut=373, copyProc=0x8544700 <fbCopyNtoN>, bitPlane=0, closure=0x0)
    at fbcopy.c:558
#12 0x08545861 in fbCopyArea (pSrcDrawable=0x8ccf968, pDstDrawable=0x8bd95a0,
    pGC=0x8cc9df0, xIn=0, yIn=0, widthSrc=40, heightSrc=40, xOut=498, yOut=373)
    at fbcopy.c:596
#13 0x0837e03b in XAACopyAreaFallback (pSrc=0x8ccf968, pDst=0x8bd95a0,
    pGC=0x8cc9df0, srcx=0, srcy=0, width=40, height=40, dstx=498, dsty=373)
    at xaaFallback.c:83
#14 0x0837fb33 in XAACopyArea (pSrcDrawable=0x8ccf968, pDstDrawable=0x8bd95a0,
    pGC=0x8cc9df0, srcx=0, srcy=0, width=40, height=40, dstx=498, dsty=373)
    at xaaCpyArea.c:70
#15 0x0864339d in miSpriteCopyArea (pSrc=0x8ccf968, pDst=0x8bd95a0,
    pGC=0x8cc9df0, srcx=0, srcy=0, w=40, h=40, dstx=498, dsty=373)
    at misprite.c:1190
#16 0x08637466 in miDCRestoreUnderCursor (pScreen=0x8b81058, x=498, y=373,
    w=40, h=40) at midispcur.c:536
#17 0x08646b6d in miSpriteRemoveCursor (pScreen=0x8b81058) at misprite.c:2256
#18 0x08642285 in miSpritePaintWindowBackground (pWin=0x8cea6e8,
    pRegion=0x8cf0200, what=0) at misprite.c:842
#19 0x08623e86 in miWindowExposures (pWin=0x8cea6e8, prgn=0x8cf0200,
    other_exposed=0x0) at miexpose.c:536
#20 0x084a2a2f in xf86XVWindowExposures (pWin=0x8cea6e8, reg1=0x8cf0200,
    reg2=0x0) at xf86xv.c:1035
#21 0x0861ab62 in miHandleValidateExposures (pWin=0x8bd95a0) at miwindow.c:468
#22 0x0849574c in xf86SetRootClip (pScreen=0x8b81058, enable=1)
#23 0x08495828 in xf86EnableDisableFBAccess (scrnIndex=0, enable=1)
    at xf86Helper.c:1178
#24 0x08378de3 in XAAEnableDisableFBAccess (index=0, enable=1) at xaaInit.c:755
#25 0x08493463 in xf86VTSwitch () at xf86Events.c:1374
#26 0x08492eba in xf86Wakeup (blockData=0x0, err=-1, pReadmask=0x8b67460)
    at xf86Events.c:1149
#27 0x084eafcb in WakeupHandler (result=-1, pReadmask=0x8b...

[Fabio Massimo Di Nitto (fabbione)]

Ok thanks.. i will look at it, but i doubt i can manage a fix for warty.

Fabio

[Daniel Stone (daniels)]

This is hairy, so I'm deferring to Hoary (I crack me up), at the very least.
Reporting upstream, as well

[Daniel Stone (daniels)]

Is this fixed in X.Org, which is available in our Hoary Hedgehog development branch?

[Martijn vdS (martijn)]

It still breaks.

[Daniel Stone (daniels)]

Thanks dude, will have a look at it.

[Noam Samuel (noamsml)]

(In reply to comment #0)
> If a program tries to show a large windows while I'm switching back to X from
> another VT, the X server tends to crash. This happened with both gdm
> (ctrl+alt+f1 while you still see the black/white pattern, then alt+f7 while gdm
> is done starting, for example)
>
> You'll see a silhouette of the affected window, filled in the background color,
> but somehow the X server crashes after that.
>
> This means I can't close the lid on my laptop, as sometimes X crashes before
> turning the monitor back on (and nothing can seem to turn it back on after
> that), while sometimes it crashes with the silhouette of the "xscreensaver
> password window" showing.

workaround for lid problem: backup /etc/acpi/events/lidbtn and then remove it.
restore it when the VT bug is fixed.

[Daniel Stone (daniels)]

does option NoScreenToScreenCopy fix this? i'd be curious to see why it's
falling back.

[Matt Zimmerman (mdz)]

(In reply to comment #15)
> does option NoScreenToScreenCopy fix this? i'd be curious to see why it's
> falling back.

Can you try this, please?

[Martijn vdS (martijn)]

Option "XaaNoScreenToScreenCopy" does not fix this problem.

[Martijn vdS (martijn)]

Option "NoAccel" does not solve the problem, either

[Daniel Robitaille (robitaille)]

Martijn,

Do you know if this is still occurring in Dapper?

[Martijn vdS (martijn)]

It did before I sold the laptop (in January)

[Corey Burger (corey.burger)]

Martijn, do you have any way of testing this bug now? If not, it should be closed.

[Martijn vdS (martijn)]

I do not. But I don't think that bugs should be closed just because there's nobody to test them (a bug is a bug until it's fixed, imho :))

[Rocco Stanzione (trappist)]

If it can't be reproduced, it probably isn't a bug and almost certainly won't be fixed. Closing at any rate due to inactivity. If anyone can reproduce this, please reopen the bug.

[Martijn vdS (martijn)]

Reopen, as this is still a bug.

[Bryce Harrington (bryce)]

Closing as out of date and unreproduceable