Bug 50084

Created attachment 61791 [details]
this is how it should look like

Created attachment 61792 [details]
Xorg.log

Any particular font configuration for xterm? Is there a particular sequence you need to trigger the corruption? Does it redraw correctly? It's working for me with default xterm under xfce4 (with and without compositing) on debian/sid.

(In reply to comment #3)
> Any particular font configuration for xterm?

None that I'm aware of. These should be standard fixed utf8 fonts.

> Is there a particular sequence you
> need to trigger the corruption? 

No, it cannot be reproduced reliably. It happens "sometimes", unexpectedly.

> Does it redraw correctly?

Yes, ctrl-l cures that.

> It's working for me
> with default xterm under xfce4 (with and without compositing) on debian/sid.

This is KDE 4.8 on opensuse with (xrender) effects enabled if that helps somehow.

Thanks, that tells me the suspect is the sna_reversed_glyph_blt() function (or perhaps one of its callers) and that is one of the rare effects, such as using clipping or crossing a boundary...

Any ideas for reproducing this here? Have you noticed a pattern for when the corruption occurs?

(In reply to comment #6)
> Any ideas for reproducing this here? Have you noticed a pattern for when the
> corruption occurs?

Not yet, it happens pretty randomly...

(In reply to comment #7)
> (In reply to comment #6)
> > Any ideas for reproducing this here? Have you noticed a pattern for when the
> > corruption occurs?
> 
> Not yet, it happens pretty randomly...

Hmm, it looks like it happens sometimes when I press ctrl-r in xterm for reverse searching, find something and press enter. Then the command is moved left few characters (to be right after PS1) while being corrupted.

Created attachment 62568 [details]
shifted cursor

Sometimes, after switching from desktop to desktop, it happens that the cursor is rendered one or more lines below actual line. Like in the image.

I am truly puzzled. :(

Just to check, you are up to date with the latest fixes, in particular the flushing fix from a few days ago?

(In reply to comment #10)
> Just to check, you are up to date with the latest fixes, in particular the
> flushing fix from a few days ago?

Which one exactly? I'm at a65c3b7b45.

I was thinking of

commit 08a630dc5ef87e551865e558fe4fc45ea66457b4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 30 08:50:44 2012 +0100

    sna: Ensure we flush scanout even when otherwise idle.

which you have.

Bisection might be an option here... Should I try?

Honestly, no. My suspicion is that we are exercising an error condition in some corner case and the commit will only be indirectly related to the breakage, even so it may still be a good enough clue. I would only proceed iff you have an absolute 100% reliable trigger, in which case I would have expected to have seen this on my box as well by now :(

(In reply to comment #14)
> I would only proceed iff you have an absolute 100% reliable trigger

Nah, I don't have a trigger for this :/...

I suspect this bug is

commit ab3b7fe31b5a9d7924e959f21d29c4f7352ec8cb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 13 10:35:14 2012 +0100

    sna: Only reuse a write buffer if all external references have been dropped
    
    This avoids the unhappy situation of overwriting an upload buffer that
    we intend to use for a fallback.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

(In reply to comment #16)
> I suspect this bug is
> 
> commit ab3b7fe31b5a9d7924e959f21d29c4f7352ec8cb
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Jun 13 10:35:14 2012 +0100
> 
>     sna: Only reuse a write buffer if all external references have been dropped

I'm now at 2.19.0-261-g85a749e, but still the cursor is sometimes rendered on a wrong line like in comment #9. I haven't seen text with lines missing yet.

(In reply to comment #17)
> I'm now at 2.19.0-261-g85a749e

Which makes no sense to you, I guess. This is 0db789e18 plus my fix for two compiler warnings.

(In reply to comment #17)
> I haven't seen text with lines missing yet.

Happened now. With 221534abe2dc04fae8b8fc332104bca275d4863b.

BTW the cursor is rendered at the right place. But there is missing a PS1 text before that. It happens like this:

Before:
/tmp> echo ahoy
ahoy
/tmp> X

After:
/tmp> echo ahoy

      X

Where X is cursor. The rest of the text is cleared (replaced by old contents). Sometimes it happens that "echo ahoy" is rendered with lines missing.

(In reply to comment #20)
> BTW the cursor is rendered at the right place. But there is missing a PS1 text
> before that. It happens like this:
> 
> Before:
> /tmp> echo ahoy
> ahoy
> /tmp> X
> 
> After:
> /tmp> echo ahoy
> 
>       X
> 
> Where X is cursor. The rest of the text is cleared (replaced by old contents).
> Sometimes it happens that "echo ahoy" is rendered with lines missing.

Ok, that's kind of what I expected, except I couldn't rule the possibility of there being a composited offset bug due to switching desktops. Improbable just not impossible. The question just becomes where did that test go, and who dropped it?

More damage fixes, can you confirm that this bug still exists. (I'd be shocked if those fixed it though.)

Do you have to leave the terminal invisible on the other desktop for a few minutes before switching back to trigger the missing lines?

(In reply to comment #23)
> Do you have to leave the terminal invisible on the other desktop for a few
> minutes before switching back to trigger the missing lines?

I can't tell for sure. It doesn't look like that. Closing a terminal on another desktop at the same place does not necessarily mean this artefact will emerge.

When cleaning up the fb fallout, I did spot one place where I was using the GC for a cpu operation without first moving the GC itself to the CPU (that has a few side effects such as computing the reduce raster operation and/xor). Out of optimism, did that fix the occasional corruption in xterm?

(In reply to comment #25)
> Out of
> optimism, did that fix the occasional corruption in xterm?

You're too optimistic :). It still happens with ea9ec18505645dfec8.

:(

Ok, I'll dream of finding a test case and meanwhile ponder a way of capturing the right debug info.

I would say it is fixed with 1a0590d. I didn't appear for some time.

I had been entertaining theories about some broken behaviour on gen3...

Glad to hear it has disappeared, for the time being at least! :)