xterm has some rendering problems. Some pixels are not erased or
something like that. I don't know how to reproduce this. When this
occurred (twice), there was an emacs window partly covering the
xterm one.

See attached snapshot as an example: there's a dot above "Xgc"
and another one on the right. But the first time this problem
occurred, whole characters were remaining (and the left one was
half visible).

If this is new, when did it start occurring?  Could also be a driver or
X issue.

Cheers,
Julien

From the description and picture, I'm assuming it's a duplicate of #463784

Just before reporting the bug. I couldn't reproduce the bug yet.

Hmm... perhaps. When I moved a window over the xterm window, the
xterm contents were redrawn correctly. If the driver or X is in
charge of this, this would mean the bug comes from it.

I don't think so. BTW, I use the "fixed" font.

ok...  I would expect #463784 only for relatively uncommon fonts (or
from fontconfig changes - they've been tinkering with the font metrics).

found 640464 276-1
thanks

Similar problem after doing a next search in "less", while an Emacs
window was partially covering the xterm window. The part above the
Emacs window was drawn with incorrect characters. Moving the Emacs
window over the xterm window (without touching xterm) made the
display problem disappear, showing that this is just a rendering
bug.

I can now reproduce the problem almost 100% of the time. Actually
that's the top-left part that is incorrect. I'll provide some
screenshots.

the xtrace output could be useful. I've attached an archive containing
the xtrace output xterm.xtrace and 3 screenshots, obtained with
"import -window root <file.png>".

Here are the details of what I did:
 1. Put the Emacs window partly over the xterm window.
 2. Typed "man curl".
 3. Searched for "https".
 4. Quit "less".
 5. Typed "man curl" again.
 6. Took the 1st screenshot (xterm1.png).
 7. Searched for "https" again. The bug appeared.
 8. Took the 2nd screenshot (xterm2.png).
 9. Moved to another desktop.
10. Moved back to the original desktop: xterm was redrawn correctly.
11. Took the 3rd screenshot (xterm3.png).
12. Quit "less".
13. Quit xterm.

Note: I don't know what is this black rectangle that appears on the left
in the screenshots. It didn't appear on the screen of my laptop. Also,
I had to type "man curl" twice because the bug doesn't appear the first
time (this is unrelated to the fact I took a screenshot or not).

Which window manager are you using?

Which window manager are you using?

fvwm

I'm baffled by this one (not able to reproduce the problem).

In my initial response, I had in mind that perhaps the optimization that I did
in #274/#275 to discard extra configure-events, and extra exposures (due to
rapid scrolling) was the problem.  If I could reproduce it, I'd do that with
the debugging traces and re-examine the changes from #274/#275.

Your xtrace output is showing only a few exposure events:

5.711 000:>:010b: Event Expose(12) window=0x02c00018 x=9 y=0 width=484 height=784 count=0x0000
5.711 000:>:010b: Event Expose(12) window=0x02c00019 x=0 y=0 width=8 height=784 count=0x0000
11.726 000:>:0242: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=108 width=275 height=3329 minor-opcode=0x000d count=0x0000 major-opcode=0x3e
11.729 000:>:024d: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=108 width=275 height=3329 minor-opcode=0x000d count=0x0000 major-opcode=0x3e
11.731 000:>:025e: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=82 width=275 height=9985 minor-opcode=0x0027 count=0x0000 major-opcode=0x3e
26.349 000:>:0396: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=108 width=275 height=3329 minor-opcode=0x000d count=0x0000 major-opcode=0x3e
26.351 000:>:03a5: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=108 width=275 height=3329 minor-opcode=0x000d count=0x0000 major-opcode=0x3e
26.353 000:>:03c2: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=17 width=275 height=26625 minor-opcode=0x0068 count=0x0000 major-opcode=0x3e
27.995 000:>:0455: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=43 width=275 height=19969 minor-opcode=0x004e count=0x0000 major-opcode=0x3e
34.750 000:>:053f: Event GraphicsExposure(13) drawable=0x02c00018 x=216 y=2 width=275 height=30465 minor-opcode=0x0077 count=0x0000 major-opcode=0x3e
45.532 000:>:0560: Event Expose(12) window=0x02c00018 x=9 y=0 width=484 height=121 count=0x0002
45.532 000:>:0560: Event Expose(12) window=0x02c00018 x=9 y=121 width=207 height=503 count=0x0001
45.532 000:>:0560: Event Expose(12) window=0x02c00018 x=9 y=624 width=484 height=160 count=0x0000
45.532 000:>:0560: Event Expose(12) window=0x02c00019 x=0 y=0 width=8 height=784 count=0x0000

Some of the heights look too large to me, those at 26.353 and 27.995,
and the GraphicsExposure widths all look too small (perhaps those are
the highlighting - but still, I'd expect more than just that).

This type of problem is also possible in the X server - usually for
specific drivers.

(My display here is just vesa - mostly am using Parallels on Mac OS X -
so the X server tends to be more stable than some of the drivers).

a different machine with xterm_271-1_amd64.deb.

Note: the same driver is used (nouveau).

and with various xterm versions, even an old one like 260.

So, I'm starting to think that the problem comes from the nouveau
driver.

No, downgrading *nouveau* and the X server to old versions doesn't
make the problem disappear. However the problem disappeared after
downgrading libx11* packages. I'll try to investigate more later.

Just to remember:

dpkg -i /var/cache/apt/archives/libx11-6_2%3a1.4.3-1_amd64.deb /var/cache/apt/archives/libx11-data_2%3a1.4.3-1_all.deb /var/cache/apt/archives/libx11-dev_2%3a1.4.3-1_amd64.deb /var/cache/apt/archives/libx11-protocol-perl_0.56-2_all.deb /var/cache/apt/archives/libx11-xcb1_2%3a1.4.3-1_amd64.deb

After doing tests on another machine, this is not related to the
libx11* packages (in some cases, the problem doesn't occur, and it
might be the case here). I'm not even sure that this is a regression,
but in such a case, I don't know why I didn't notice it before. For
the moment, I've tried to downgrade packages as shown in attachment
(downgrade1), and the bug still occurs (after a reboot).

To reproduce the bug, I've attached a file "text", obtained from
xterm logging (md5sum: e522fe4b2a4e45e39761550e8a5426f7). The steps
are the following:

1. Type: xterm -geometry 80x60 -e 'sleep 10; cat text; sleep 999'
2. Put a smaller window covering the middle of the right part of
   the xterm window.
3. Wait for the text (from "cat text").

In case this is due to the driver, I use the nouveau driver (both
machines have a NVIDIA card).

reassign 640464 xserver-xorg-video-nouveau
found 640464 1:0.0.16+git20101210+8bb8231-2
found 640464 1:0.0.16+git20111201+b5534a1-1
thanks

The bug no longer occurs when I downgrade to xorg 1:7.5+8 (with
all the dependencies); see attachment concerning the downgrade.
Thus I assume that it is a bug in the nouveau driver (I wanted
to try with vesa, but vesa doesn't work at all).

The bug seems to have appeared between

  xserver-xorg-video-nouveau 1:0.0.15+git20100329+7858345-4

and

  xserver-xorg-video-nouveau 1:0.0.16+git20101210+8bb8231-2

tags 640464 - moreinfo
thanks

According to my tests, it doesn't occur with

  xorg 1:7.5+8
  xserver-xorg-video-nouveau 1:0.0.15+git20100329+7858345-4

and occurs with

  xorg 1:7.6+4
  xserver-xorg-video-nouveau 1:0.0.16+git20101210+8bb8231-2

and later.

The way to reproduce the bug is described in

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464#82

Warning! It doesn't seem to be 100% reproducible, but almost.

Yes, it seems so, but I don't know which.

It would be interesting if you could try rebuilding and running the
newer driver version against the older xserver-xorg-core version (or
vice versa) and see if the problem occurs like that. That should tell us
whether the problem was introduced by a change in the driver or X
server.

This is not really possible, because xserver 1.8 has been required by
the driver since 2010-10-22 (commit a4d580bf05d).

I'm not sure if this will work out either, at least cherry-picking
commit 964eeac6dc2 is probably necessary.

Cheers,
       Sven

Information given by lshw run as root:

           *-display
                description: VGA compatible controller
                product: G98M [Quadro NVS 160M]
                vendor: NVIDIA Corporation
                physical id: 0
                bus info: pci@0000:01:00.0
                version: a1
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
                configuration: driver=nouveau latency=0
                resources: irq:16 memory:f5000000-f5ffffff memory:e0000000-efffffff memory:f2000000-f3ffffff ioport:df00(size=128) memory:f4000000-f401ffff

and for the other machine:

           *-display
                description: VGA compatible controller
                product: G98 [Quadro NVS 295]
                vendor: NVIDIA Corporation
                physical id: 0
                bus info: pci@0000:0f:00.0
                version: a1
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
                configuration: driver=nouveau latency=0
                resources: irq:24 memory:e2000000-e2ffffff memory:d0000000-dfffffff memory:e0000000-e1ffffff ioport:d000(size=128)

fdbug49786.sh script (this is a standalone testcase) and wait
for 4 seconds. It just needs xterm and base64 (to output some
content with special chracters).

I've attached screenshots:
  * snapshot1.png: what is obtained after running the script. Incorrect.
  * snapshot2.png: what is obtained after a redraw. Correct.

Control: tags -1 upstream

I've attached a new version of my script, as the behavior may depend
on a non-default config. It should be better now.

The bug has been confirmed with this script on the upstream BTS:

  Ilia Mirkin 2013-08-21 14:25:22 UTC

  Great repro script! Bug confirmed on my NV96, and disconfirmed on
  NV18. I see that your card is a NV98, so this is probably a bug in
  the nv50 exa logic.

This bug seems to be fixed in xserver-xorg-video-nouveau 1:1.0.10-1.

I'll try to do more tests on a machine where I haven't upgraded yet,
e.g. by recompiling xserver-xorg-video-nouveau alone in order to make
sure that this comes from a change in xserver-xorg-video-nouveau and
not a side effect of an upgrade of other packages.

Note: when doing the test above, I killed the compositor first
(compton), and I did the following two tests:
  * running the script for this bug 640464;
  * resizing an Emacs window.
Both didn't show any bug (resizing a window is affected by bug 727549
when compton is running, so that if I get resize information, this
means compton was no longer running, i.e. it was really killed).
I can't reproduce this behavior.

After another reboot, the bug no longer occurs!

And if I log out and log in again, kill compton, the bug still no
longer occurs. Perhaps something sometimes occurs at boot time,
which makes the bug no longer occur.

I've attached the log files (/var/log/Xorg.0.log, /var/log/boot
[the part of the last boot], and dmesg output), in case there may
be something interesting.