Subject: Bug#648764: More informative backtrace

From: Jan Oberländer <[email-masked]>
Date: Mon, 14 Nov 2011 22:23:20 +0100

Hello again,

I suppose it's a good thing this bug reproduces so well. :)  Here's a
better backtrace.

-- gdb output:
Program received signal SIGABRT, Aborted.
0xb75d3424 in __kernel_vsyscall ()
(gdb) bt full
#0  0xb75d3424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb72a4911 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        resultvar = <optimized out>
        pid = -1220739084
        selftid = 4517
#2  0xb72a7d42 in *__GI_abort () at abort.c:92
        act = {__sigaction_handler = {sa_handler = 0xb7280504, sa_sigaction = 0xb7280504}, sa_mask = {__val = {3074233328, 696, 3074233280, 3074228212, 3074233280, 101, 3213901904, 3073283037, 3103953888, 3074228212, 3074228212, 102, 
              3213902104, 3073218216, 3102636304, 3102636304, 101, 3103953888, 0, 4222451712, 3102636304, 3102636405, 3102636304, 3102636304, 3102636405, 3102636604, 3102636304, 3102636604, 0, 0, 0, 0}}, sa_flags = 0, sa_restorer = 0x4}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#3  0xb729db28 in *__GI___assert_fail (assertion=0xb6f98287 "boi->space_accounted", file=0xb6f9826a "../../radeon/radeon_cs_gem.c", line=181, function=0xb6f982ba "cs_gem_write_reloc") at assert.c:81
        buf = 0xb8fff898 "Xorg: ../../radeon/radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.\n"
#4  0xb6f96384 in ?? () from /usr/lib/i386-linux-gnu/libdrm_radeon.so.1
No symbol table info available.
#5  0xb6f971a2 in radeon_cs_write_reloc () from /usr/lib/i386-linux-gnu/libdrm_radeon.so.1
No symbol table info available.
#6  0xb705ae55 in R200TextureSetupCP (pPict=0xb904a8a0, pPix=<optimized out>, unit=0) at ../../src/radeon_exa_render.c:878
        _ret = <optimized out>
        pScrn = 0xb8ab08f0
        info = 0xb8ab0d48
        txfilter = 285212672
        txformat = 3098264344
        txoffset = 0
        txpitch = 6912
        w = 0
        h = 2
        repeatType = <optimized out>
        repeat = 198
        i = <optimized out>
        driver_priv = 0xb8f8b308
        __head = 0x0
        __expected = 2
        __count = 0
        __func__ = "R200TextureSetupCP"
#7  0xb706629f in R200PrepareCompositeCP (op=3, pSrcPicture=0xb904a8a0, pMaskPicture=0x0, pDstPicture=0xb9002020, pSrc=0xb903db48, pMask=0x0, pDst=0xb8fa3430) at ../../src/radeon_exa_render.c:1021
        pScrn = 0xb8ab08f0
        info = 0xb8ab0d48
        dst_format = <optimized out>
        dst_pitch = <optimized out>
        pp_cntl = <optimized out>
        blendcntl = <optimized out>
        cblend = <optimized out>
        ablend = <optimized out>
        colorpitch = 1728
        pixel_shift = <optimized out>
        driver_priv = <optimized out>
        __head = 0x0
        __expected = 2
        __count = 0
        __func__ = "R200PrepareCompositeCP"
#8  0xb6fc07ca in exaTryDriverComposite (op=3 '\003', pSrc=0xb904a8a0, pMask=0x0, pDst=0xb9002020, xSrc=316, ySrc=138, xMask=0, yMask=0, xDst=1, yDst=<optimized out>, width=536, height=185) at ../../exa/exa_render.c:759
        pExaScr = 0xb8ace278
        region = {extents = {x1 = 1, y1 = 0, x2 = 537, y2 = 185}, data = 0x0}
        pbox = <optimized out>
        nbox = <optimized out>
        src_off_x = <optimized out>
        src_off_y = <optimized out>
        mask_off_x = <optimized out>
        mask_off_y = <optimized out>
        dst_off_x = 0
        dst_off_y = 0
        pSrcPix = 0xb903db48
        pMaskPix = 0x0
        pDstPix = 0xb8fa3430
        pSrcExaPix = 0xb9030001
        pMaskExaPix = <optimized out>
#9  0xb6fc12e2 in exaComposite (op=3 '\003', pSrc=0xb904a8a0, pMask=0x0, pDst=0xb9002020, xSrc=316, ySrc=138, xMask=0, yMask=0, xDst=1, yDst=0, width=536, height=185) at ../../exa/exa_render.c:1033
        isSrcSolid = <optimized out>
        pExaScr = 0x0
        ret = <optimized out>
        saveSrcRepeat = 0
        saveMaskRepeat = 0
        region = {extents = {x1 = 1, y1 = 0, x2 = 537, y2 = 185}, data = 0xb8ace1d8}
#10 0xb76fd70b in damageComposite (op=3 '\003', pSrc=0xb904a8a0, pMask=0x0, pDst=0xb9002020, xSrc=316, ySrc=138, xMask=0, yMask=0, xDst=1, yDst=0, width=536, height=185) at ../../../miext/damage/damage.c:569
        pScreen = <optimized out>
        ps = 0xb8ace040
        pScrPriv = 0xb8ace1d8
#11 0xb76f01ae in CompositePicture (op=<optimized out>, pSrc=0xb904a8a0, pMask=0x0, pDst=0xb9002020, xSrc=316, ySrc=138, xMask=0, yMask=0, xDst=1, yDst=0, width=536, height=185) at ../../render/picture.c:1647
        ps = 0xb8ace040
#12 0xb76f564c in ProcRenderComposite (client=0xb8ee5af8) at ../../render/render.c:728
        pSrc = 0xb904a8a0
        pMask = 0x0
        pDst = 0xb9002020
        stuff = 0xb906bc10
#13 0xb76f0aa1 in ProcRenderDispatch (client=0xb8ee5af8) at ../../render/render.c:2063
        stuff = <optimized out>
#14 0xb762c657 in Dispatch () at ../../dix/dispatch.c:432
        clientReady = 0xb8e4d8b0
        result = <optimized out>
        client = 0xb8ee5af8
        nready = 0
        icheck = 0xb77f3078
        start_tick = 60060
#15 0xb761a25a in main (argc=10, argv=0xbf9047d4, envp=0xbf904800) at ../../dix/main.c:287
        i = <optimized out>
        alwaysCheckForInput = {0, 1}

---

From: Cyril Brulebois <[email-masked]>
Date: Tue, 15 Nov 2011 00:51:34 +0100

Hi,

> I suppose it's a good thing this bug reproduces so well. :)  Here's a

thanks for that. But you could also install libdrm's debug packages I
think. ;-)

(Getting a core and exploiting it afterwards is usually a nice idea: you
can install more packages as needed, without having to get a new crash.
Hints at http://x.debian.net/howto/use-gdb.html)

> No symbol table info available.

^^^^
for those

Mraw,
KiBi.

---

From: Michel Dänzer <[email-masked]>
Date: Tue, 15 Nov 2011 16:48:11 +0100

> > No symbol table info available.

That shouldn't be necessary. As in the other bug, the libdrm_radeon
assertion failure is probably just a symptom of the bug in the radeon
driver.

-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

---

From: Michel Dänzer <[email-masked]>
Date: Thu, 17 Nov 2011 11:24:24 +0100

> #7  0xb706629f in R200PrepareCompositeCP (op=3, pSrcPicture=0xb904a8a0, pMaskPicture=0x0, pDstPicture=0xb9002020, pSrc=0xb903db48, pMask=0x0, pDst=0xb8fa3430) at ../../src/radeon_exa_render.c:1021

Can you try if the patch below fixes this crash?

diff --git a/src/radeon_exa_render.c b/src/radeon_exa_render.c
index e5c231f..6cead5a 100644
--- a/src/radeon_exa_render.c
+++ b/src/radeon_exa_render.c
@@ -595,6 +595,9 @@ RADEONPrepareCompositeCS(int op, PicturePtr pSrcPicture, PicturePtr pMaskPicture
     if (info->cs) {
 	int ret;
 
+	if (CS_FULL(info->cs))
+	        radeon_cs_flush_indirect(pScrn);
+
 	radeon_cs_space_reset_bos(info->cs);
 
 	radeon_add_pixmap(info->cs, pSrc,

---

From: Jan Oberländer <[email-masked]>
Date: Thu, 24 Nov 2011 22:20:41 +0100

Hi,

> Can you try if the patch below fixes this crash?

Sorry for the late reply, I've been out of town.  I'll see if I can try
your patch this weekend.

Best,
Jan

---

From: Jan Oberländer <[email-masked]>
Date: Sat, 26 Nov 2011 22:43:10 +0100

> Can you try if the patch below fixes this crash?

Heh.  I wish I could tell you.  Before testing the patch I tried to
reproduce the crash, just to make sure I could actually tell it was gone
afterwards.  Turns out I can't reproduce it anymore, because WordPress
(where I originally encountered the crash, reliably) seem to have
changed something in their web interface, and I can't reproduce the
crash anymore.  I haven't installed any upgrades since I reported the
bug, so my system's behavior should still be the same.  Murphy's Law, I
guess. :)

Testing out your patch at least didn't make anything worse.  But I'm
going back to the original version right now to wait and see if I can
discover some other way to reproduce the crash.

Maybe you have an idea of how I could reproduce it, based on the gdb
trace I sent?

Best,

Jan

-- 

+-------------------------------------+
| Jan Oberländer   <[email-masked]> |
|         PGP key: 0xC4D910E3         |
+-------------------------------------+

---

From: Michel Dänzer <[email-masked]>
Date: Mon, 05 Dec 2011 17:46:23 +0100

> Maybe you have an idea of how I could reproduce it, based on the gdb

Not really, unfortunately.

If you encounter a similar problem in the future, you could try creating
a trace of the triggering operations, e.g. with cairo-trace.