Bug 13407

Created attachment 12743 [details]
xorg.conf

Same problem occurs (ie. a crash shortly after desktop startup, eg. starting a terminal and typing something) if I remove AccelDFS, GARTSize and EnablePageFlip lines. The problem disappears if I uncomment the RenderAccel false line.

Created attachment 12744 [details]
Xorg.0.log

Does this also happen with Option "EXANoComposite" instead of "RenderAccel" "false"? (What's the problem with the default of Option "RenderAccel"?)

Can you get a more useful backtrace from gdb?

EXANoComposite fixes the problem. I also found this undocumented (?) MigrationHeuristic and noticed that Option "MigrationHeuristic" "greedy" seems to fix the problem, too. But without them, here's the trace with gdb:

#0  0xb7a6f594 in RADEONHostDataBlit (pScrn=0x821d2f0, cpp=4, w=0, 
    dstPitchOff=8021772, bufPitch=0xbf8fb764, x=0, y=0xbf8fb788, h=0xbf8fb790, 
    hpass=0xbf8fb768) at ../../src/radeon_accel.c:699
#1  0xb7aa7929 in RADEONUploadToScreenCP (pDst=0x84a2928, x=0, y=0, w=0, h=2, 
    src=0x8471bd0 "", src_pitch=0) at ../../src/radeon_exa_funcs.c:272
#2  0xb78d5349 in exaGlyphs (op=3 '\003', pSrc=0x84a2dc8, pDst=0x850c228, 
    maskFormat=0x0, xSrc=0, ySrc=0, nlist=0, list=0xbf8fbde4, 
    glyphs=0xbf8fb9f4) at ../../exa/exa_render.c:1199
#3  0x08172604 in damageGlyphs (op=216 '�', pSrc=0x84a2dc8, pDst=0x850c228, 
    maskFormat=0x825ecc0, xSrc=<value optimized out>, 
    ySrc=<value optimized out>, nlist=1, list=0xbf8fbde4, glyphs=0xbf8fb9e4)
    at ../../../miext/damage/damage.c:658
#4  0x08159b5a in CompositeGlyphs (op=<value optimized out>, pSrc=0x84a2dc8, 
    pDst=0x850c228, maskFormat=0x825ecc0, xSrc=0, ySrc=0, nlist=1, 
    lists=0xbf8fbde4, glyphs=0xbf8fb9e4) at ../../render/picture.c:1785
#5  0x081614e9 in ProcRenderCompositeGlyphs (client=0x84aba20)
    at ../../render/render.c:1403
#6  0x0815c875 in ProcRenderDispatch (client=0x0) at ../../render/render.c:2002
#7  0x0814feee in XaceCatchExtProc (client=0x84aba20) at ../../Xext/xace.c:299
#8  0x0808d93f in Dispatch () at ../../dix/dispatch.c:502
#9  0x080747ab in main (argc=10, argv=0xbf8fc684, envp=Cannot access memory at address 0x8
)
    at ../../dix/main.c:452

(In reply to comment #4)
> EXANoComposite fixes the problem.

I don't understand how that can cause exaGlyphs to behave differently from "RenderAccel" "off" though. When this happens, is pExaScr->info->PrepareComposite == NULL in the exaGlyphs frame?

> I also found this undocumented (?) MigrationHeuristic

It's documented in the exa(4) manpage.

> and noticed that Option "MigrationHeuristic" "greedy" seems
> to fix the problem, too.

It probably just happens to avoid it because it tends to keep pixmaps out of offscreen memory, preventing acceleration.

Sorry for the delay. After two "up":s:
#2  0xb78a7349 in exaGlyphs (op=3 '\003', pSrc=0x8b03010, pDst=0x8b03178, 
    maskFormat=0x0, xSrc=0, ySrc=0, nlist=0, list=0xbfa56f44, 
    glyphs=0xbfa56b54) at ../../exa/exa_render.c:1199
(gdb) print pExaScr->info->PrepareComposite
$1 = (Bool (*)(int, PicturePtr, PicturePtr, PicturePtr, PixmapPtr, PixmapPtr, 
    PixmapPtr)) 0xb7a76640 <R200PrepareCompositeCP>

Created attachment 12913 [details] [review]
Possible fix, backport from master branch

Ah, I was confused by RenderAccel being disabled in the attached xorg.conf, so I didn't understand the problem correctly...

Does this patch fix it?

Yes! Confirming that applying that patch fixes the problem for me, I cannot get it to crash anymore. To be fool-proof, I also removed the patch, rebuilt again and switched back and forth between the builds to see that it's really fixing it.

Okay, marking as a blocker for 1.4.1.

Adding the patch keyword.

pushed, thanks.