Xorg+intel segfault at Awesome startup after gdk/gtk+ update (was
Fwd: Re: Awesome stopped working after upgrade other pkgs)
Pierre Guinoiseau
geekounet at poildetroll.net
Sun Dec 5 12:31:23 UTC 2010
Hi,
as the subject says, Xorg with the intel driver segfault at awesome startup
since the last gdk/gtk+ update. See below the forwarded mail from awesome-devel
ML for a description of the problem and a backtrace. I can give more
informations if needed. :)
Related installed packages:
xorg-server-1.7.5,1
xf86-video-intel-2.7.1_3
gdk-pixbuf-2.22.1
gtk-2.22.1_1
awesome-3.4.8
Thanks,
Pierre
----- Forwarded message from Pierre Guinoiseau <geekounet at poildetroll.net> -----
Message-ID: <20101205025733.GA40142 at tritus.poildetroll.net>
References: <AANLkTi=6anBWYnJy-BmaPuBJLXuFBfhfQk+k6jAxf2uM at mail.gmail.com> <sa3zkt0fi9k.fsf at cigue.easter-eggs.fr>
In-Reply-To: <sa3zkt0fi9k.fsf at cigue.easter-eggs.fr>
Date: Sun, 5 Dec 2010 03:57:33 +0100
From: Pierre Guinoiseau <geekounet at poildetroll.net>
Organization: Poil de Troll
To: Renato Botelho <rbgarga at gmail.com>, awesome at naquadah.org
List-Id: <awesome.naquadah.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Operating-System: FreeBSD
X-Spam-Level:
Subject: Re: Awesome stopped working after upgrade other pkgs
Hi,
I have the same problem since an upgrade to gtk-2.22.1_1 on my FreeBSD 8.1 (so I
think gdk may be the cause of the problem), it happens only with the intel
driver, it works fine with radeon. Running xterm alone or even an entire KDE
session doesn't crash X, only running awesome does.
Here is a backtrace of X:
(gdb) bt
#0 0x000000080169fa1c in kill () from /lib/libc.so.7
#1 0x000000080169e9a3 in abort () from /lib/libc.so.7
#2 0x00000000004742f4 in ddxGiveUp ()
#3 0x000000000046fe2d in AbortServer ()
#4 0x00000000004704af in FatalError ()
#5 0x000000000046f941 in OsInit ()
#6 <signal handler called>
#7 i830_get_pixmap_bo (pixmap=0x0) at i830_exa.c:789
#8 0x00000008021f7c4c in i965_set_picture_surface_state (ss_bo=0x8157ff340, ss_index=1, pPicture=0x8157fee00, pPixmap=0x0, is_dst=0) at i965_render.c:927
#9 0x00000008021f7fa5 in i965_prepare_composite (op=8, pSrcPicture=0x8157fee00, pMaskPicture=0x8157ff280, pDstPicture=0x8157fed40, pSrc=0x0, pMask=0x818004000, pDst=0x8171f0000) at i965_render.c:1301
#10 0x0000000802a17cdc in exaTryDriverCompositeRects (op=Variable "op" is not available.
) at exa_render.c:442
#11 0x0000000802a19447 in exaCompositeRects (op=3 '\003', pSrc=0x8157fee00, pMask=0x8157ff280, pDst=0x8157fed40, nrect=3, rects=0x7fffffffc198) at exa_render.c:601
#12 0x0000000802a157b2 in exaGlyphsToDst (pSrc=Variable "pSrc" is not available.
) at exa_glyphs.c:633
#13 0x0000000802a15fae in exaGlyphs (op=3 '\003', pSrc=0x8157fee00, pDst=0x8157fed40, maskFormat=0x0, xSrc=0, ySrc=9, nlist=1, list=0x7fffffffe310, glyphs=0x7fffffffdb28) at exa_glyphs.c:844
#14 0x00000000004bcbd7 in DamageRegionAppend ()
#15 0x00000000004b5315 in PanoramiXRenderReset ()
#16 0x000000000044ec50 in Dispatch ()
#17 0x000000000042c8da in main ()
(gdb) frame 7
#7 i830_get_pixmap_bo (pixmap=0x0) at i830_exa.c:789
789 if (i830->accel == ACCEL_UXA) {
(gdb) info frame
Stack level 7, frame at 0x7fffffffbe20:
rip = 0x8021ea0c4 in i830_get_pixmap_bo (i830_exa.c:789); saved rip 0x8021f7c4c
called by frame at 0x7fffffffbe90, caller of frame at 0x7fffffffb9c8
source language c.
Arglist at 0x7fffffffbe08, args: pixmap=0x0
Locals at 0x7fffffffbe08, Previous frame's sp is 0x7fffffffbe20
Saved registers:
rax at 0x7fffffffba18, rbx at 0x7fffffffba20, rcx at 0x7fffffffba00, rdx at 0x7fffffffb9f8, rsi at 0x7fffffffb9f0, rdi at 0x7fffffffb9e8, rbp at 0x7fffffffba28, r8 at 0x7fffffffba08, r9 at 0x7fffffffba10, r10 at 0x7fffffffba30, r11 at 0x7fffffffba38, r12 at 0x7fffffffba40, r13 at 0x7fffffffba48,
r14 at 0x7fffffffba50, r15 at 0x7fffffffba58, rip at 0x7fffffffbe18, eflags at 0x7fffffffba90, cs at 0x7fffffffba88, ss at 0x7fffffffbaa0
Obviously, pixmap=0x0 seems wrong, as the intel code does things like pixmap->foo (see below), and it seems to be related to composite, thought I tested without xcompmgr and the result is still the same...
xf86-video-intel-2.7.1/src/i830_exa.c:
dri_bo *
i830_get_pixmap_bo(PixmapPtr pixmap)
{
ScreenPtr screen = pixmap->drawable.pScreen;
ScrnInfoPtr scrn = xf86Screens[screen->myNum];
I830Ptr i830 = I830PTR(scrn);
#ifdef I830_USE_UXA
if (i830->accel == ACCEL_UXA) {
>-------return dixLookupPrivate(&pixmap->devPrivates, &uxa_pixmap_index);
}
#endif
#ifdef XF86DRM_MODE
if (i830->accel == ACCEL_EXA) {
>-------struct i830_exa_pixmap_priv *driver_priv =
>------- exaGetPixmapDriverPrivate(pixmap);
>-------return driver_priv ? driver_priv->bo : NULL;
}
#endif
return NULL;
}
I don't know how to debug this more than this, but if you tell me how to, I will. :)
I find it wrong that a X client can crash the X server like that, so I think the
main problem to fix may be an unhandled error case in the X/intel code, but the
pixmap=0 thing is weird too, there may be a problem on both side... so maybe we
should forward this problem to the X/intel ML too?
Pierre
On 23/11/2010 11:26:15, Julien Danjou <julien at danjou.info> wrote:
> On Tue, Nov 23 2010, Renato Botelho wrote:
>
> > If I user other window manager it works fine (i'm back to wmaker right
> > now). My question is, how can I debug it? is there a verbose mode on
> > awesome? I couldn't find it.
>
> That's the X server crashing for an unknown reason. Start gdb and get a
> backtrace. :)
>
> --
> Julien Danjou
> // ᐰ <julien at danjou.info> http://julien.danjou.info
>
> --
> To unsubscribe, send mail to awesome-unsubscribe at naquadah.org.
----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20101205/c7fb0fcd/attachment.pgp
More information about the freebsd-x11
mailing list