bug#26153: 26.0.50; Garbage displayed at visual line boundaries

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

[-- Attachment #1: test.el.gz --]
[-- Type: application/gzip, Size: 2485 bytes --]

[-- Attachment #2: 1489837793.png --]
[-- Type: image/png, Size: 195311 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1323 bytes --]


In the last weeks a new issue crept up in the display engine. Some
visual garbage is drawn at the horizontal lower/upper edge when using
hl-line-mode, on the region, or anything that redraws the current visual
line to fill the background.

See the attached screenshot, captured with emacs -Q on the current
master, with the lucid toolkit.

Evaluate the test file, then move the pointer down one line at a time,
until garbage is visible.

Changing the font weight seems necessary to trigger this issue, as well
some hidden properties in the line. I wasn't able to reproduce it easily
otherwise.

This seems to have been introduced around commit
d546be31a9320d94769cb322f008f49d08d852a8 ("Fix display of
mouse-highlight produced by overlapping overlays") or earlier.

If the exact commit would be helpful, I can try to pinpoint it.


Configured using:
 'configure --with-x-toolkit=lucid --without-gconf --without-gsettings
 --with-modules 'CFLAGS=-O3 -march=native -pipe '
 LDFLAGS=-fwhole-program'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL LIBSELINUX GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11
MODULES LIBSYSTEMD

Important settings:
  value of $LC_COLLATE: C
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Date: Sat, 18 Mar 2017 13:00:40 +0100
> 
> In the last weeks a new issue crept up in the display engine. Some
> visual garbage is drawn at the horizontal lower/upper edge when using
> hl-line-mode, on the region, or anything that redraws the current visual
> line to fill the background.
> 
> See the attached screenshot, captured with emacs -Q on the current
> master, with the lucid toolkit.
> 
> Evaluate the test file, then move the pointer down one line at a time,
> until garbage is visible.

I don't see any garbage when I do this, but maybe that's because my
Emacs is built without optimizations.  Or maybe this is specific to X?

> Changing the font weight seems necessary to trigger this issue

Tried that, it didn't help.

> as well some hidden properties in the line.

What does this mean in practice?  What should I try changing?

> This seems to have been introduced around commit
> d546be31a9320d94769cb322f008f49d08d852a8 ("Fix display of
> mouse-highlight produced by overlapping overlays") or earlier.
> 
> If the exact commit would be helpful, I can try to pinpoint it.

Please do, as the above commit had to do with mouse-highlight, which I
don't see in your recipe.

Thanks.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Date: Sat, 18 Mar 2017 13:00:40 +0100
> 
> In the last weeks a new issue crept up in the display engine. Some
> visual garbage is drawn at the horizontal lower/upper edge when using
> hl-line-mode, on the region, or anything that redraws the current visual
> line to fill the background.

Your hl-line face seems to use bold, does your region face use bold as
well?

And which other kinds of "anything that redraws the current visual
line to fill the background" did you see which leave these artifacts
on the screen?

Also, does "C-l" or "M-x redraw-display RET" remove these artifacts?

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
> Your hl-line face seems to use bold, does your region face use bold as
> well?

No

> And which other kinds of "anything that redraws the current visual
> line to fill the background" did you see which leave these artifacts
> on the screen?

It's hard to tell, since this happens usually while programming, so I
have some minor modes that can affect the display.

> Also, does "C-l" or "M-x redraw-display RET" remove these artifacts?

C-l doesn't remove the artifacts, even when pressed multiple times
(causing the buffer to scroll).

But redraw-display does actually remove them.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
>> Evaluate the test file, then move the pointer down one line at a time,
>> until garbage is visible.
>
> I don't see any garbage when I do this, but maybe that's because my
> Emacs is built without optimizations.  Or maybe this is specific to X?

No idea here. But I suppose so.

>> as well some hidden properties in the line.
>
> What does this mean in practice?  What should I try changing?

The test case I provided is 100% reliable for me.

> Please do, as the above commit had to do with mouse-highlight, which I
> don't see in your recipe.

This might take a while.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 26153@debbugs.gnu.org
> Date: Sat, 18 Mar 2017 15:28:08 +0100
> 
> > Please do, as the above commit had to do with mouse-highlight, which I
> > don't see in your recipe.
> 
> This might take a while.

Thanks, there's no rush.  Alternatively, a more reliable test case
will do.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
> Thanks, there's no rush.  Alternatively, a more reliable test case
> will do.

Uhm, old versions fail to build at the dumping step for me.
I guess because of the change in glibc's malloc?

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 26153@debbugs.gnu.org
> Date: Sat, 18 Mar 2017 17:22:17 +0100
> 
> On Sat, Mar 18 2017, Eli Zaretskii wrote:
> > Thanks, there's no rush.  Alternatively, a more reliable test case
> > will do.
> 
> Uhm, old versions fail to build at the dumping step for me.
> I guess because of the change in glibc's malloc?

That depends on what old versions you are trying to build.  The issues
with glibc's malloc should have been fixed long ago, so if you are
bisecting the latest month or two, it shouldn't pop up.

Which version did you specify as the "good" one initially?  Your
original report told "in the last weeks", so I presumed your last
version that worked correctly was just a few weeks ago, at most.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
> That depends on what old versions you are trying to build.  The issues
> with glibc's malloc should have been fixed long ago, so if you are
> bisecting the latest month or two, it shouldn't pop up.

I couldn't find a "good" version yet :/
I can reproduce the issue further back, more than I imagined.
I only verified that the emacs-25 tag is not affected so far.

I was trying to build a version around the fix for #24109 which should
be ok according to memory, but it fails to build.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 26153@debbugs.gnu.org
> Date: Sat, 18 Mar 2017 18:10:57 +0100
> 
> On Sat, Mar 18 2017, Eli Zaretskii wrote:
> > That depends on what old versions you are trying to build.  The issues
> > with glibc's malloc should have been fixed long ago, so if you are
> > bisecting the latest month or two, it shouldn't pop up.
> 
> I couldn't find a "good" version yet :/
> I can reproduce the issue further back, more than I imagined.
> I only verified that the emacs-25 tag is not affected so far.

Could it be that the problem was caused by some change in your system,
rather than a change in Emacs?

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
>> I couldn't find a "good" version yet :/
>> I can reproduce the issue further back, more than I imagined.
>> I only verified that the emacs-25 tag is not affected so far.
>
> Could it be that the problem was caused by some change in your system,
> rather than a change in Emacs?

Well, I'm using debian unstable, so yes, it could.

But this would mean that whatever it is, it's not affecting a build of
emacs 25.2.1.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Yuri D'Elia wrote:
> Uhm, old versions fail to build at the dumping step for me.
> I guess because of the change in glibc's malloc?

On some versions gmalloc fails to build.
On others, dumping just fails with a segmentation fault.

I cannot bisect easily like this.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 26153@debbugs.gnu.org
> Date: Sat, 18 Mar 2017 18:46:55 +0100
> 
> On Sat, Mar 18 2017, Yuri D'Elia wrote:
> > Uhm, old versions fail to build at the dumping step for me.
> > I guess because of the change in glibc's malloc?
> 
> On some versions gmalloc fails to build.
> On others, dumping just fails with a segmentation fault.
> 
> I cannot bisect easily like this.

Sorry about that.  Did you try configuring with REL_ALLOC=no?  That
is,

  REL_ALLOC=no ./configure ...

This should avoid at least the problems with segfaults during dumping.

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
> Sorry about that.  Did you try configuring with REL_ALLOC=no?  That
> is,
>
>   REL_ALLOC=no ./configure ...
>
> This should avoid at least the problems with segfaults during dumping.

No difference :/

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 26153@debbugs.gnu.org
> Date: Sat, 18 Mar 2017 20:31:56 +0100
> 
> On Sat, Mar 18 2017, Eli Zaretskii wrote:
> > Sorry about that.  Did you try configuring with REL_ALLOC=no?  That
> > is,
> >
> >   REL_ALLOC=no ./configure ...
> >
> > This should avoid at least the problems with segfaults during dumping.
> 
> No difference :/

Too bad.

Can you try disabling double buffering?  Like this:

  (add-to-list 'default-frame-alist '(inhibit-double-buffering . t))

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Yuri D'Elia]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Sat, Mar 18 2017, Eli Zaretskii wrote:
> Can you try disabling double buffering?  Like this:
>
>   (add-to-list 'default-frame-alist '(inhibit-double-buffering . t))

Ah! This affects the issue.

By showing the same buffer on two frames, the original frame shows the
problem, the new frame without double-buffering does not show any
artifact.

Screenshot attached. Old frame (with double-buffering) on the top.
This is the same emacs instance showing the same buffer.


[-- Attachment #2: 1489866056.png --]
[-- Type: image/png, Size: 175342 bytes --]

bug#26153: 26.0.50; Garbage displayed at visual line boundaries

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: 26153@debbugs.gnu.org
> Date: Sat, 18 Mar 2017 20:42:41 +0100
> 
> On Sat, Mar 18 2017, Eli Zaretskii wrote:
> > Can you try disabling double buffering?  Like this:
> >
> >   (add-to-list 'default-frame-alist '(inhibit-double-buffering . t))
> 
> Ah! This affects the issue.
> 
> By showing the same buffer on two frames, the original frame shows the
> problem, the new frame without double-buffering does not show any
> artifact.
> 
> Screenshot attached. Old frame (with double-buffering) on the top.
> This is the same emacs instance showing the same buffer.

Thanks for testing.

Daniel, could you please take a look?