Bug 67504

Can you recompilewith --enable-debug=full, then grab a gdb "bt full" and attach the Xorg.0.log?

Note that sna->scrn being NULL there is an indication of memory corruption, as X cannot start unless it sets that. An alternate possibility it that the BlockHandler is running after we shutdown... Again, I think impossible.

I did recompile with full debug but unfortunately, I do not manage to crash it with the same procedure. Everything is a lot slower however, so maybe timing is important.

I suspected memory corruption as well as triggering the crash seems to rely there being consideral memory load on the system.

Would valgrind help (you'd need to tell me how to run that with X though)?

Reinstalling the non-debug version again and I can reproduce quite easily again:

gdb) bt full
#0  has_offload_slaves (sna=0x7f0eb6568000) at sna_accel.c:14700
        screen = <optimized out>
        dirty = <optimized out>
#1  0x00007f0eb78796ee in stop_flush (scanout=0x214a660, sna=0x7f0eb6568000)
    at sna_accel.c:14763
No locals.
#2  sna_accel_flush (sna=0x7f0eb6568000) at sna_accel.c:14985
        priv = 0x214a660
        busy = false
#3  sna_accel_block_handler (sna=0x7f0eb6568000, tv=0x7fff2aed2c58)
    at sna_accel.c:15425
No locals.
#4  0x000000000043d9c4 in BlockHandler (
    pTimeout=pTimeout@entry=0x7fff2aed2c58, 
    pReadmask=pReadmask@entry=0x81c340 <LastSelectMask>) at dixutils.c:387
        i = 0
        j = <optimized out>
#5  0x0000000000469e84 in WaitForSomething (
    pClientsReady=pClientsReady@entry=0x23a7a30) at WaitFor.c:210
        i = <optimized out>
        waittime = {tv_sec = 153, tv_usec = 65000}
        wt = 0x7fff2aed2c60
        timeout = <optimized out>
---Type <return> to continue, or q <return> to quit---
        clientsReadable = {fds_bits = {0 <repeats 16 times>}}
        clientsWritable = {fds_bits = {1, 1, 4294967295, 5415558, 34730504, 
            140733913574944, 34712528, 0, 34712528, 34730504, 0, 206158430224, 
            140733913574960, 140733913574752, 16, 264619602646}}
        selecterr = <optimized out>
        nready = 0
        devicesReadable = {fds_bits = {55, 1, 140733913574912, 48, 43118368, 
            4689382, 48, 43118368, 50831424, 4651885, 1, 48, 0, 0, 0, 
            46284816}}
        now = <optimized out>
        someReady = 0
#6  0x0000000000439581 in Dispatch () at dispatch.c:357
        clientReady = 0x23a7a30
        result = <optimized out>
        client = <optimized out>
        nready = <optimized out>
        icheck = 0x8163f0 <checkForInput>
        start_tick = <optimized out>
#7  0x00000000004282da in main (argc=9, argv=0x7fff2aed3068, 
    envp=<optimized out>) at main.c:298
        i = <optimized out>
        alwaysCheckForInput = {0, 1}

just compiled 2.21.13 as it is supposed to fix some mem corruption, but it still crashes...

Can you try CFLAGS="-O0 -g3" ./configure <blah>?

To use valgrind, do ./configure --enable-debug, then I find it easier to launch X by hand, so something like:

$ sudo valgrind --trace-children /usr/bin/Xorg -ac -noreset 2>&1 | tee /tmp/xorg.txt

switch back to a second VT, or login in remotely, then
$ DISPLAY=:0 gnome-session

switch back to X

Running under valgrind, you will notice a slowdown, but not quite as much as perhaps you would imagine.

with O0 -g3 it was not so easy to trigger, but:

Program received signal SIGSEGV, Segmentation fault.
0x00007f1472b8b88c in has_offload_slaves (sna=0x7f1471868000)
    at sna_accel.c:14747
14747	ScreenPtr screen = sna->scrn->pScreen;
(gdb) bt full
#0  0x00007f1472b8b88c in has_offload_slaves (sna=0x7f1471868000)
    at sna_accel.c:14747
        screen = 0x2085620
        dirty = 0x7fff0733c890
#1  0x00007f1472b8ba3b in stop_flush (sna=0x7f1471868000, scanout=0x207aa60)
    at sna_accel.c:14810
No locals.
#2  0x00007f1472b8c1bf in sna_accel_flush (sna=0x7f1471868000)
    at sna_accel.c:15032
        priv = 0x207aa60
        busy = false
#3  0x00007f1472b8cf29 in sna_accel_block_handler (sna=0x7f1471868000, 
    tv=0x7fff0733c998) at sna_accel.c:15472
No locals.
#4  0x00007f1472ba67d8 in sna_block_handler (arg=0x2054420, 
    timeout=0x7fff0733c998, read_mask=0x81c340 <LastSelectMask>)
    at sna_driver.c:557
        sna = 0x7f1471868000
        tv = 0x7fff0733c998
#5  0x000000000043d9c4 in BlockHandler (
    pTimeout=pTimeout@entry=0x7fff0733c998, 
    pReadmask=pReadmask@entry=0x81c340 <LastSelectMask>) at dixutils.c:387
        i = 0
---Type <return> to continue, or q <return> to quit---
        j = <optimized out>
#6  0x0000000000469e84 in WaitForSomething (
    pClientsReady=pClientsReady@entry=0x22e29d0) at WaitFor.c:210
        i = <optimized out>
        waittime = {tv_sec = 296, tv_usec = 432000}
        wt = 0x7fff0733c9a0
        timeout = <optimized out>
        clientsReadable = {fds_bits = {0 <repeats 16 times>}}
        clientsWritable = {fds_bits = {1, 1, 0, 34103520, 0, 0, 33899552, 
            5413855, 33899552, 46103504, 77595664, 206158430224, 
            140733314222960, 140733314222752, 46041312, 264619602646}}
        selecterr = <optimized out>
        nready = 0
        devicesReadable = {fds_bits = {57, 1, 140733314222912, 32, 46103344, 
            4689382, 32, 46103344, 51602000, 4651885, 0, 32, 0, 0, 0, 
            46103440}}
        now = <optimized out>
        someReady = 0
#7  0x0000000000439581 in Dispatch () at dispatch.c:357
        clientReady = 0x22e29d0
        result = <optimized out>
        client = <optimized out>
        nready = <optimized out>
---Type <return> to continue, or q <return> to quit---
        icheck = 0x8163f0 <checkForInput>
        start_tick = <optimized out>
#8  0x00000000004282da in main (argc=9, argv=0x7fff0733cda8, 
    envp=<optimized out>) at main.c:298
        i = <optimized out>
        alwaysCheckForInput = {0, 1}
(gdb) 

Valgrind will have to wait until tomorrow at least...

Next time you see a crash, please p *sna and p *sna->scrn

Created attachment 83493 [details]
gdb output

Work is keeping my too busy, so it took some time. Anyway, finally did manage to get the gdb output at least.

Ok, this is starting to make sense. Buffer overflow in the relocation array. If you run with --enable-debug this should trigger an assertion. So if you could recompile and run under gdb, that would be invaluable. Meanwhile I'll look for paths where I've made an incorrect check.

I think I understand it:

commit 5287660aafe45859c07874c22dca99c1ff5e555a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 2 13:18:12 2013 +0100

    sna: Reserve relocation entries for the deferred VBO
    
    Whilst we reserved exec entry slots for the deferred VBO, there were no
    relocation spaces reserved. So if we submitted a render command followed
    by a multitude of BLT copies, we could then overrun the relocation array
    when adding the deferred vbo to the batch.
    
    Reported-by: Danny <moondrake@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67504
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Please do check that this indeed fixes the problem, thanks!

You're quicker than I had time to recompile with debug. As far as i can tell, this has fixed the issue. Should it change, i will let you know. Thanks!

d.

Created attachment 83666 [details]
File name glitch

If i have a file or folder, and its name is more than 1 line, if i select part of the name in 2 or more lines, then the rest of the text in lines with selected text is not black, but white.

glitch? Behaves the same for sna/uxa/fb, so I presume the bug is in the rendering commands i.e. higher up the stack.