glitches in editor

[dimich]

Spurous characters appear in editor when open certain files with F4 (mc-xterm-F4.png).

The issue is reproduced in xterm, urxvt (mc-urxvt-F4.png) and virtual console, regardless of syntax highlight enabled or disabled.

Sometimes glitches remain after exit from editor (mc-xterm-F4-exit.png).

Redrawing screen by Ctrl+L removes glitches.

Example file to reproduce the issue attached.

When mcedit run from command line, sometimes top status line is not shown (mcedit-xterm.png). Ctrl+L forces top status line to display.

The issue is not reproduced in mc-4.8.31.

[dimich]

Edit file with F4 in xterm

[dimich]

Glitches remain after exit from editor

[dimich]

Glitches in urxvt

[dimich]

Top status line not shown

[dimich]

Example file

[andrew_b]

I'm unable to reproduce this.

[zaytsev]

You did read how to create a defect report, right? No OS, no locale, no mc information. There is no way to debug your problem.

[dimich]

OS: Arch Linux, kernel 6.10.6-arch1-1, glibc 2.40.

mc version is specified in the ticket: Version: 4.8.32

The issue is reproduced with default locale, i.e.:
$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

The issue is reproduced without any custom configuration, i.e. /etc/mc and ~/.config/mc removed.

It is NOT reproduced the same way under different users. But once glitches appear in mc instance running under one user, they also appear in another instance running under another user.

It is NOT reproduced in mc-4.8.31.

I cannot reproduce the issue on another machine with the same OS, windom manager and other settings. Relevant difference between systems may be that one where i observe the issue has integrated Intel graphics, another one where i can't reproduce it has discrette Nvidia graphics. I have no idea how this difference may affect.

Let me know if any additinal information required.

[andrew_b]

Since it is not reproduced in mc-4.8.31 and stable reproduced in mc-4.8.32 for you, git bisect is the way to find a bad commit:

git bisect start
git bisect bad 4.8.32
git bisect good 4.8.31

Then compile, test and mark the current commit as
git bisect bad
or
git bisect good.

[zaytsev]

I think the problem might be with the C locale. I've seen glitches before when viewing binary files or editing some files with funny stuff in them. In theory we should not output any unprintable characters in single byte mode, but I never felt like it was worth dealing that stuff. Can you try with a clean UTF-8 locale and see if you get any glitches to confirm that?

Andrew, what do you think? Are glitches in single-byte locales a feature or a bug in your opinion?

[dimich]

Seems I found the root cause of the issue.
In Arch mc is built with aspell support (./configure ... --enable-aspell ...) but i have no aspell package installed. If aspell libraries are installed the issue is not reproduced, and vice versa.
Looks like inablility to load aspell libraries leads to some kind of undefined behavior.
It's up to you to decide whether this is a mc bug or not.

[andrew_b]

Replying to zaytsev:

I think the problem might be with the C locale.

Probably not with C locale only but with single-byte one. But in my case (KOI8-R) there is no such glithes.

I've seen glitches before when viewing binary files or editing some files with funny stuff in them. In theory we should not output any unprintable characters in single byte mode, but I never felt like it was worth dealing that stuff. Can you try with a clean UTF-8 locale and see if you get any glitches to confirm that?

Andrew, what do you think? Are glitches in single-byte locales a feature or a bug in your opinion?

Apparently, it's not good: #2180, #2453.

[zaytsev]

Looks like inablility to load aspell libraries leads to some kind of undefined behavior.

So it's valid for both 4.8.31 and 4.8.32?

This is very strange, the only fishy thing I can see is the call of g_module_close on NULL. Does the following help?

diff --git a/src/editor/spell.c b/src/editor/spell.c
index 1f9aeba60..2dcbe0027 100644
--- a/src/editor/spell.c
+++ b/src/editor/spell.c
@@ -174,6 +174,9 @@ spell_available (void)
 
     spell_module = g_module_open ("libaspell", G_MODULE_BIND_LAZY);
 
+    if (spell_module == NULL)
+        return FALSE;
+
     if (spell_module != NULL
         && ASPELL_FUNCTION_AVAILABLE (new_aspell_config)
         && ASPELL_FUNCTION_AVAILABLE (aspell_dict_info_list_elements)

[dimich]

So it's valid for both 4.8.31 and 4.8.32?

I see no any malfunction with 4.8.31 when aspell is not installed, only with 4.8.32. ./configure options are the same for both versions.

This is very strange, the only fishy thing I can see is the call of g_module_close on NULL. Does the following help?
+ if (spell_module == NULL)
+ return FALSE;

Yes, the patch seems to fix the issue. At least it is not reproduced in the same environment.

As I can see with gdb, g_module_close() does a lot even if module==NULL. Looks like it tries to set an error code.

I have glib2 2.80.4 installed, if that matters.

[zaytsev]

I see no any malfunction with 4.8.31 when aspell is not installed, only with 4.8.32.

Ok, thank you, maybe it is related to 0749b6d2d3352805691d1e38e8c1b7daf230a05d - could be that g_module_close does something it didn't do before.

Yes, the patch seems to fix the issue. At least it is not reproduced in the same environment.

Sounds good, thanks for reporting and testing. Andrew are you ok for me to commit?

[andrew_b]

Replying to zaytsev:

Andrew are you ok for me to commit?

Yes, please.

[andrew_b]

Committed to master: [876555035a0ba61167180c0a59890e66d2d66902].

[dimich]

Thank you.

FYI, git bisect found out that this commit introduced the issue: 822ef80f5b5da035ae41f8d0940cbc51293814f9

[zaytsev]

That makes sense, so we did it before, but it was lost upon refactoring, thanks!

[zaytsev]

Reported to GLib:

​https://gitlab.gnome.org/GNOME/glib/-/issues/3459