Help with debuging Xserver / Goes in an infinite loop

Joshua C. joshuacov at googlemail.com
Mon Oct 5 21:05:54 UTC 2009


2009/10/5 Adam Jackson <ajax at redhat.com>:
> On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
>
>> (gdb) bt
>> #0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
>> #1  0x00000000004e615a in WaitForSomething (
>>     pClientsReady=<value optimized out>) at WaitFor.c:228
>> #2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
>> #3  0x000000000042d205 in main (argc=<value optimized out>,
>>     argv=0x7fffa2ac9218, envp=<value optimized out>) at main.c:397
>
> Okay, this isn't the server actually taking 100% of the CPU (almost
> certainly), it's before that.  If you type 'cont' to resume, and then ^C
> the gdb process once the CPU goes wild, you should break back to the gdb
> prompt; _that_'s the backtrace I need.
>
> Of course, you might not, in which case debugging this gets a bit
> harder.
>
> - ajax
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

(gdb) handle SIGUSR1 nostop
Signal        Stop      Print   Pass to program Description
SIGUSR1       No        Yes     Yes             User defined signal 1
(gdb) handle SIGUSR2 nostop
Signal        Stop      Print   Pass to program Description
SIGUSR2       No        Yes     Yes             User defined signal 2
(gdb) handle SIGPIPE nostop
Signal        Stop      Print   Pass to program Description
SIGPIPE       No        Yes     Yes             Broken pipe
(gdb) cont
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
#1  0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
arg=0x7fff78cabbc0) at xf86drm.c:187
#2  0x0000003cd600335c in drmCommandWriteRead (fd=8,
drmCommandIndex=<value optimized out>, data=0x7fff78cabbc0,
size=<value optimized out>)
    at xf86drm.c:2363
#3  0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf=<value
optimized out>) at radeon_bufmgr_gem.c:282
#4  0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
index=0) at radeon_exa.c:279
#5  0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
index=0) at exa.c:523
#6  0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
index=0, pReg=0x0) at exa.c:543
#7  0x00007f6c69beceac in ExaCheckComposite (op=<value optimized out>,
pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=<value optimized
out>,
    ySrc=<value optimized out>, xMask=0, yMask=0, xDst=19, yDst=85,
width=55, height=18) at exa_unaccel.c:342
#8  0x00007f6c69beb564 in exaComposite (op=<value optimized out>,
pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=<value optimized
out>,
    ySrc=<value optimized out>, xMask=0, yMask=0, xDst=19, yDst=85,
width=55, height=18) at exa_render.c:967
#9  0x000000000052eb90 in damageComposite (op=8 '\b', pSrc=<value
optimized out>, pMask=<value optimized out>, pDst=0x27a04b0, xSrc=1,
ySrc=0,
    xMask=<value optimized out>, yMask=<value optimized out>, xDst=19,
yDst=85, width=55, height=<value optimized out>) at damage.c:643
#10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
#11 0x00000000004471d4 in Dispatch () at dispatch.c:456
#12 0x000000000042d205 in main (argc=<value optimized out>,
argv=0x7fff78cac198, envp=<value optimized out>) at main.c:397




More information about the fedora-devel-list mailing list