Bug#648764: More informative backtrace
On Sam, 2011-11-26 at 22:43 +0100, Jan Oberländer wrote: > On Thu, Nov 17, 2011 at 11:24:24AM +0100, Michel Dänzer wrote: > > 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? 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1323103583.11335.503.camel@thor.local
Bug#648764: More informative backtrace
On Thu, Nov 17, 2011 at 11:24:24AM +0100, Michel Dänzer wrote: > 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| | PGP key: 0xC4D910E3 | +-+ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2026214310.GA17385@hex
Bug#648764: More informative backtrace
Hi, On Thu, Nov 17, 2011 at 11:24:24AM +0100, Michel Dänzer wrote: > 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 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2024212041.GA3273@hex
Bug#648764: More informative backtrace
On Mon, 2011-11-14 at 22:23 +0100, Jan Oberländer wrote:
>
> #6 0xb705ae55 in R200TextureSetupCP (pPict=0xb904a8a0, pPix=,
> unit=0) at ../../src/radeon_exa_render.c:878
> #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,
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1321525464.3794.90.camel@thor.local
Bug#648764: More informative backtrace
On Die, 2011-11-15 at 00:51 +0100, Cyril Brulebois wrote: > > Jan Oberländer (14/11/2011): > > I suppose it's a good thing this bug reproduces so well. :) Here's a > > better backtrace. > > 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) > > > -- gdb output: > > #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. > > > for those 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 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1321372091.16559.36.camel@thor.local
Bug#648764: More informative backtrace
Hi, Jan Oberländer (14/11/2011): > I suppose it's a good thing this bug reproduces so well. :) Here's a > better backtrace. 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) > -- gdb output: > #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. for those Mraw, KiBi. signature.asc Description: Digital signature
Bug#648764: More informative backtrace
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 =
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 }}
#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=,
unit=0) at ../../src/radeon_exa_render.c:878
_ret =
pScrn = 0xb8ab08f0
info = 0xb8ab0d48
txfilter = 285212672
txformat = 3098264344
txoffset = 0
txpitch = 6912
w = 0
h = 2
repeatType =
repeat = 198
i =
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 =
dst_pitch =
pp_cntl =
blendcntl =
cblend =
ablend =
colorpitch = 1728
pixel_shift =
driver_priv =
__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=, 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 =
nbox =
src_off_x =
src_off_y =
mask_off_x =
mask_off_y =
dst_off_x = 0
dst_off_y = 0
pSrcPix = 0xb903db48
pMaskPix = 0x0
pDstPix = 0xb8fa3430
pSrcExaPix = 0xb9030001
pMaskExaPix =
#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 =
pExaScr = 0x0
ret =
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 =
ps = 0xb8ace040
pScrPriv = 0xb8ace1d8
#11 0xb76f01ae in CompositePicture (op=, 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 =
#14 0xb762c657 in Dispatch () at ../../dix/dispatch.c:432
clientReady = 0xb8e4d8b0
result =
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 =
alwaysCheckForInput = {0, 1}
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014212320.GA5526@hex
