[vim/vim] GVim UI freezes (Issue #12671)

175 views
Skip to first unread message

Vít Ondruch

unread,
Jul 14, 2023, 9:15:21 AM7/14/23
to vim/vim, Subscribed

Steps to reproduce

  1. Open some file in GVim from terminal, in my case it might be $ gvim rubygem-excon.spec
  2. Do something else in some other windows, typically switch to browser or terminal
  3. Once get back to GVim, the UI is mostly frozen. Moving the mouse above, the mouse cursor changes its direction like from LTR / RTL text.
  4. The only option appears to close the GVim window and start from scratch

Expected behaviour

GVim keeps working no matter where I switch

Version of Vim

vim-X11-9.0.1671-1.fc39.x86_64

Environment

Fedora Rawhide
Gnome Terminal

Logs and stack traces

No response


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671@github.com>

Vít Ondruch

unread,
Jul 14, 2023, 9:17:55 AM7/14/23
to vim/vim, Subscribed

I'd say that I observe similar behavior for years now, but recently it got very prominent.

One thing I realized writing this that this really might be somehow related to detaching from terminal. Maybe I should try to run $ gvim rubygem-excon.spec &


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1635853539@github.com>

Vít Ondruch

unread,
Jul 14, 2023, 9:22:22 AM7/14/23
to vim/vim, Subscribed

It might even been due to using two screens. It feels like some positioning algorithm got completely lost.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1635859301@github.com>

Christian Brabandt

unread,
Jul 14, 2023, 9:27:16 AM7/14/23
to vim/vim, Subscribed

Does it only happen in an X11 environment? Are you using X11 or Wayland? Can you reproduce using vim --clean?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1635865303@github.com>

Vít Ondruch

unread,
Jul 14, 2023, 5:22:33 PM7/14/23
to vim/vim, Subscribed

Does it only happen in an X11 environment? Are you using X11 or Wayland? Can you reproduce using vim --clean?

I am running Wayland session. I'll give a try to vim --clean


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1636457544@github.com>

VZ

unread,
Jul 17, 2023, 11:55:54 AM7/17/23
to vim/vim, Subscribed

I think I'm seeing the same bug under Gnome 43.4 with Wayland (but under Debian Bookworm and not Fedora). It happens with -u NONE -U NONE too and can be relatively easily (although not 100% reliably) reproduced by switching workspaces using the keyboard.

I've tried having a quick look at this but it's not easy to understand what's going on because Vim doesn't really "hang", per se, because it still processes events and returns to the main loop, but just never handles them correctly for some reason. Here is the stack if you break into a "hung" Vim:

0  0x00007fbd25d139ae in g_main_context_poll
    (priority=<optimized out>, n_fds=4, fds=0x5615d959ac20, timeout=<optimized out>, context=0x5615d94a6490)
    at ../../../glib/gmain.c:4553
#1  g_main_context_iterate
    (context=context@entry=0x5615d94a6490, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../../../glib/gmain.c:4243
#2  0x00007fbd25d13acc in g_main_context_iteration (context=0x5615d94a6490, context@entry=0x0, may_block=may_block@entry=1)
    at ../../../glib/gmain.c:4313
#3  0x00005615d7376eac in gui_mch_wait_for_chars (wtime=4000) at ./src/vim-gtk3/gui_gtk_x11.c:6526
#4  0x00005615d730ed0c in ui_wait_for_chars_or_timer
    (wtime=4000, wait_func=0x5615d73652e0 <gui_wait_for_chars_3>, interrupted=0x7ffdb9224f6c, ignore_input=0)
    at ./src/vim-gtk3/ui.c:488
#5  0x00005615d730faa4 in inchar_loop
    (buf=buf@entry=0x5615d74a42c8 <typebuf_init+104> "", maxlen=maxlen@entry=53, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@
entry=756, wait_func=wait_func@entry=0x5615d73652c0 <gui_wait_for_chars_or_timer>, resize_func=resize_func@entry=0x0)
    at ./src/vim-gtk3/ui.c:384
#6  0x00005615d7365295 in gui_wait_for_chars_buf
    (buf=buf@entry=0x5615d74a42c8 <typebuf_init+104> "", maxlen=maxlen@entry=53, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@
entry=756) at ./src/vim-gtk3/gui.c:3026
#7  0x00005615d7368225 in gui_inchar
    (buf=buf@entry=0x5615d74a42c8 <typebuf_init+104> "", maxlen=maxlen@entry=53, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@
entry=756) at ./src/vim-gtk3/gui.c:3059
#8  0x00005615d730f3c9 in ui_inchar
    (buf=buf@entry=0x5615d74a42c8 <typebuf_init+104> "", maxlen=maxlen@entry=53, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@
entry=756) at ./src/vim-gtk3/ui.c:226
#9  0x00005615d71c1097 in inchar (buf=0x5615d74a42c8 <typebuf_init+104> "", maxlen=160, wait_time=-1)
    at ./src/vim-gtk3/getchar.c:3766
#10 0x00005615d71c1ee2 in vgetorpeek (advance=advance@entry=1) at ./src/vim-gtk3/getchar.c:3547
#11 0x00005615d71c3cb4 in vgetc () at ./src/vim-gtk3/getchar.c:1739
#12 0x00005615d71c4099 in safe_vgetc () at ./src/vim-gtk3/getchar.c:1990
#13 0x00005615d715763d in edit (cmdchar=cmdchar@entry=97, startln=startln@entry=0, count=<optimized out>)
    at ./src/vim-gtk3/edit.c:594
#14 0x00005615d721ae66 in invoke_edit (cap=0x7ffdb9225450, repl=<optimized out>, cmd=97, startln=0)
    at ./src/vim-gtk3/normal.c:7044
#15 0x00005615d7222ffe in normal_cmd (oap=oap@entry=0x7ffdb9225510, toplevel=toplevel@entry=1) at ./src/vim-gtk3/normal.c:939
#16 0x00005615d73bd32a in main_loop (cmdwin=cmdwin@entry=0, noexmode=noexmode@entry=0) at ./src/vim-gtk3/main.c:1535
#17 0x00005615d73be5d3 in vim_main2 () at ./src/vim-gtk3/main.c:887
#18 0x00007fbd2444618a in __libc_start_call_main
    (main=main@entry=0x5615d710a910 <main>, argc=argc@entry=2, argv=argv@entry=0x7ffdb9225788)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#19 0x00007fbd24446245 in __libc_start_main_impl
    (main=0x5615d710a910 <main>, argc=2, argv=0x7ffdb9225788, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>
, stack_end=0x7ffdb9225778) at ../csu/libc-start.c:381
#20 0x00005615d710c5b1 in _start ()

Needless to say, this is extremely annoying and makes GVim almost unusable. Also, FWIW, this had been previously reported on Reddit.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1638422381@github.com>

VZ

unread,
Jul 17, 2023, 5:12:53 PM7/17/23
to vim/vim, Subscribed

Some more information:

  1. The problem is reproducible in the latest master i.e. v9.0.1677.
  2. Vim still handles messages just fine, including keyboard ones, e.g. typing :set guifont=*<C-M> works and brings up the font selection dialog which works fine, so the problem seems to be that the window just doesn't get redrawn any longer. This also seems to be confirmed by the fact that resizing the Vim window to be bigger leaves solid black background in the new areas.
  3. Applying #9639 (and enabling it, i.e. setting GVIM_ENABLE_WAYLAND=1) avoids the problem.

I still have no idea what could be causing this, but for now using Wayland GTK backend seems like a good enough workaround.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1638889556@github.com>

Vít Ondruch

unread,
Jul 24, 2023, 5:05:20 AM7/24/23
to vim/vim, Subscribed

I'll give a try to vim --clean

Which makes no difference :(


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1647510727@github.com>

Jesse Pavel

unread,
Jul 24, 2023, 12:15:48 PM7/24/23
to vim/vim, Subscribed

I've hit a similar problem on ChromeOS using gvim, and it turned out if I did a

let &guifont = &guifont

it unblocked the UI. Does that do anything for your case?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1648215535@github.com>

Vít Ondruch

unread,
Jul 25, 2023, 3:43:08 AM7/25/23
to vim/vim, Subscribed

I've hit a similar problem on ChromeOS using gvim, and it turned out if I did a

let &guifont = &guifont

it unblocked the UI. Does that do anything for your case?

If using this command blindly when the UI is frozen is what you were suggesting, then it does not help (unless I messed it up 😉 , but the command is in the history running GVim again, so it probably was executed). Could you please elaborate why this should help?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1649300054@github.com>

Vít Ondruch

unread,
Jul 25, 2023, 4:02:40 AM7/25/23
to vim/vim, Subscribed

I wish there was a way to "soft restart" GVim. I have tried :xrestore for instance, but no luck to bring the frozen UI back to life. But the command line is still usable, so maybe there is a way to :redir > vim.log an collect some more useful information about the status of GVim


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1649324606@github.com>

Jesse Pavel

unread,
Jul 26, 2023, 12:04:03 AM7/26/23
to vim/vim, Subscribed

Could you please elaborate why this should help?

I don't have enough knowledge of internals to have any insight on why it works, but like you, when my gvim hung, I messed around until I found that I could summon the set guifont=* dialog, and changing fonts worked to unblock my GUI, and I narrowed it down to the simplest thing of setting the font to itself.

My experience with the hang is purely under Crostini's Wayland, so it may not be applicable beyond that.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1650945815@github.com>

Vít Ondruch

unread,
Aug 1, 2023, 9:08:07 AM8/1/23
to vim/vim, Subscribed

Here is the stack if you break into a "hung" Vim:

I can get similar stack on Fedora. Nevertheless, trying to step through the code, I can confirm that while the UI is frozen, the control returns back to the main_loop. So it still seems like there is somewhere lost some state.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1660276781@github.com>

Vít Ondruch

unread,
Aug 3, 2023, 11:16:44 AM8/3/23
to vim/vim, Subscribed

I suspect, that the freezes might happen just having the GVim window maximized. Or at least trying to use non-maximized window for past few hours, I have not observe the freeze. Maybe they are just less frequent ...


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1664176177@github.com>

VZ

unread,
Aug 3, 2023, 11:27:59 AM8/3/23
to vim/vim, Subscribed

I suspect, that the freezes might happen just having the GVim window maximized. Or at least trying to use non-maximized window for past few hours, I have not observe the freeze. Maybe they are just less frequent ...

I think this could be related to resizing and, more precisely, to getting an unexpected resize event. This doesn't risk to happen when the window is maximized and in my case the "unexpected" part may be due to this GNOME bug.

I still think there is something wrong in Vim, as though the GNOME issue is incredibly annoying, it doesn't make any other application hang (although all of them are susceptible to it), but making Vim maximized could well be a workaround. FWIW I've been using the version using Wayland for the last 2 weeks and have almost no problems with it (I hope to submit a patch for a problem I do see at some time...).


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1664194503@github.com>

Vít Ondruch

unread,
Aug 3, 2023, 1:56:13 PM8/3/23
to vim/vim, Subscribed

but making Vim maximized could well be a workaround.

The exact opposite actually seems to be the workaround.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1664398615@github.com>

VZ

unread,
Aug 3, 2023, 2:10:46 PM8/3/23
to vim/vim, Subscribed

but making Vim maximized could well be a workaround.

The exact opposite actually seems to be the workaround.

Oh, sorry for misunderstanding you. In this case I can definitely state that I've seen this happen without maximizing the GVim window, so at least here this is not the case.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1664417944@github.com>

Vít Ondruch

unread,
Sep 6, 2023, 6:18:26 AM9/6/23
to vim/vim, Subscribed

but making Vim maximized could well be a workaround.

The exact opposite actually seems to be the workaround.

After a while, I can confirm that this happens just when the window is maximized. I don't remember case when it would happen with normal window.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1708065326@github.com>

sfome

unread,
Nov 12, 2023, 2:07:05 PM11/12/23
to vim/vim, Subscribed

i got the same error on fedora 38
image
image


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1807212683@github.com>

Rom888

unread,
Jan 16, 2024, 12:43:27 AMJan 16
to vim/vim, Subscribed

The same issue on
Ubuntu 23.04
GNOME Shell 44.3
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 05 2023 17:29:58)


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1893104113@github.com>

sfome

unread,
Jan 16, 2024, 2:46:06 AMJan 16
to vim/vim, Subscribed

The same issue on Ubuntu 23.04 GNOME Shell 44.3 Wayland VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 05 2023 17:29:58)

can u send full vim --version plz?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1893215145@github.com>

Rom888

unread,
Jan 16, 2024, 3:12:39 AMJan 16
to vim/vim, Subscribed

vim-version.txt


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1893247407@github.com>

Vít Ondruch

unread,
Jan 16, 2024, 3:19:14 AMJan 16
to vim/vim, Subscribed

This is also still issue for me. I suspect that this really happens just on the secondary screen, which is place on the right side from the main screen. And I suspect part of the issue is different screen resolutions, where the main screen has 1920x1080 while the secondary 1920x1200. I can mostly use VIM if the window is not maximized (where the maximization is default). I think I rarely hit similar issue also with normalized window, but that is very rare.

My theory is, that VIM, for the maximized window grabs the screen resolution of the primary screen and when the window is maximized on secondary screen, it gets confused. I remember that a few moons earlier, there used to be different issue, where the content in maximized window on the secondary screen not always occupied the whole content of the window. I needed to normalize/maximize the window to workaround it. And this to me is just continuation of the issue in different form.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1893256414@github.com>

Vít Ondruch

unread,
Jan 16, 2024, 3:19:56 AMJan 16
to vim/vim, Subscribed

Unfortunately, I don't have evidence that my theory is correct :/


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1893257423@github.com>

sfome

unread,
Jan 16, 2024, 4:07:03 AMJan 16
to vim/vim, Subscribed

simply switch to xorg :) joke


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1893329103@github.com>

Capmus Banon

unread,
Jan 27, 2024, 1:18:48 AMJan 27
to vim/vim, Subscribed

The frequent hanging issue of Gvim on Wayland is a pain in the butt since I switched from Xorg half year ago. I can not believe these GVIM users and developers are the last ones migrating to Wayland. What a pity for this community.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1913027595@github.com>

Rhialto The M.

unread,
Jan 29, 2024, 3:34:09 PMJan 29
to vim/vim, Subscribed

I have a worse version of this. To reproduce:

$ vim --clean      # sometimes it only happens if you actually edit a file
:gui

The gvim window opens. It has the menu and the toolbar but not the text area. My fans start spinning - something is wasting CPU cycles, but it's not updating the window. For example, if I resize it, or cover it with another window and then uncover, it doesn't update.

This is with the currently latest version from git, and the GTK 2 gui. I'm doing this on NetBSD 9.3 and X.

Stack traces:

(gdb) thread apply all bt

Thread 1 (LWP 1 of process 321):
#0  0x0000000000636d4f in gui_gtk2_draw_string ()
#1  0x000000000062958a in gui_outstr_nowrap ()
#2  0x000000000062a390 in gui_redraw_block.part ()
#3  0x000000000062b346 in gui_redraw ()
#4  0x00000000006330e5 in expose_event ()
#5  0x00007aa9d014220d in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#6  0x00007aa9cec14c98 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0
#7  0x00007aa9cec26626 in signal_emit_unlocked_R.isra.0 () from /usr/pkg/lib/libgobject-2.0.so.0
#8  0x00007aa9cec27360 in signal_emit_valist_unlocked () from /usr/pkg/lib/libgobject-2.0.so.0
#9  0x00007aa9cec2cf43 in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0
#10 0x00007aa9cec2d000 in g_signal_emit () from /usr/pkg/lib/libgobject-2.0.so.0
#11 0x00007aa9d02565dd in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#12 0x00007aa9d01411c0 in gtk_main_do_event () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#13 0x00007aa9cfc47f37 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#14 0x00007aa9cfc47ee1 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#15 0x00007aa9cfc47ee1 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#16 0x00007aa9cfc47ee1 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#17 0x00007aa9cfc43af7 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#18 0x00007aa9cfc44756 in gdk_window_process_updates () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#19 0x00007aa9d02643f7 in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#20 0x00007aa9cec14c98 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0
#21 0x00007aa9cec25f09 in signal_emit_unlocked_R.isra.0 () from /usr/pkg/lib/libgobject-2.0.so.0
#22 0x00007aa9cec27a9d in signal_emit_valist_unlocked () from /usr/pkg/lib/libgobject-2.0.so.0
#23 0x00007aa9cec2cf43 in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0
#24 0x00007aa9cec2d000 in g_signal_emit () from /usr/pkg/lib/libgobject-2.0.so.0
#25 0x00007aa9d00c697c in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#26 0x00007aa9cfc22b51 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#27 0x00007aa9cf452cf0 in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0
#28 0x00007aa9cf455987 in g_main_context_iterate_unlocked.constprop () from /usr/pkg/lib/libglib-2.0.so.0
#29 0x00007aa9cf455efd in g_main_context_iteration () from /usr/pkg/lib/libglib-2.0.so.0
#30 0x0000000000637552 in gui_mch_update ()
#31 0x000000000062ea62 in gui_start ()
#32 0x000000000062ecb6 in ex_gui ()
#33 0x000000000048a5a3 in do_cmdline ()
#34 0x00000000004ff26d in nv_colon ()
#35 0x0000000000505d5c in normal_cmd ()
#36 0x000000000065d531 in main_loop ()
#37 0x000000000065e742 in vim_main2 ()
#38 0x00000000006691da in main ()
(gdb) 


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915514935@github.com>

Rhialto The M.

unread,
Jan 29, 2024, 3:50:19 PMJan 29
to vim/vim, Subscribed

Compiling with debugging on (adding -ggdb in strategic places in the Makefile - is there a better way?)

[Switching to LWP 1 of process 19095]
utf_ptr2len (p=p@entry=0x70775e3ca061 "") at mbyte.c:2087
2087        if (*p == NUL)
(gdb) n
2088            return 0;
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5911
5911                if ((*mb_ptr2cells)(sp) == 2 && utf_ptr2cells(bp) == 1)
(gdb) 
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x636d6b

latin_ptr2cells (p=0x70775ef8b001 "") at mbyte.c:1650
1650    }
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5927
5927                sp += (*mb_ptr2len)(sp);
(gdb) 
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x636d79

latin_ptr2len (p=0x70775ef8b001 "") at mbyte.c:1086
1086        return *p == NUL ? 0 : 1;
(gdb) 
1087    }
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5928
5928                bp += plen;
(gdb) 
5908            for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen; )
(gdb) 
5910                plen = utf_ptr2len(bp);
(gdb) 
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x636d5f

utf_ptr2len (p=p@entry=0x70775e3ca061 "") at mbyte.c:2087
2087        if (*p == NUL)
(gdb) 
2088            return 0;
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5911
5911                if ((*mb_ptr2cells)(sp) == 2 && utf_ptr2cells(bp) == 1)
(gdb) 
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x636d6b

latin_ptr2cells (p=0x70775ef8b001 "") at mbyte.c:1650
1650    }
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5927
5927                sp += (*mb_ptr2len)(sp);
(gdb) 
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x636d79

latin_ptr2len (p=0x70775ef8b001 "") at mbyte.c:1086
1086        return *p == NUL ? 0 : 1;
(gdb) 
1087    }
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5928
5928                bp += plen;
(gdb) 
5908            for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen; )
(gdb) 
5910                plen = utf_ptr2len(bp);
(gdb) 
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x636d5f

utf_ptr2len (p=p@entry=0x70775e3ca061 "") at mbyte.c:2087
2087        if (*p == NUL)
(gdb) 
2088            return 0;
(gdb) 
gui_gtk2_draw_string (row=0, col=col@entry=0, s=s@entry=0x70775ef8b000 "\b", 
    len=4, flags=flags@entry=0) at gui_gtk_x11.c:5911
5911                if ((*mb_ptr2cells)(sp) == 2 && utf_ptr2cells(bp) == 1)
(gdb) 

At first sight this identifies the infinite loop: the argument 0x70775e3ca061 in the call to utf_ptr2len() at the bottom is the same as at the top: no progress has been made.

The stack at this point is

(gdb) bt
#0  gui_gtk2_draw_string (row=0, col=col@entry=0, 
    s=s@entry=0x70775ef8b000 "\b", len=4, flags=flags@entry=0)
    at gui_gtk_x11.c:5911
#1  0x000000000062958a in gui_outstr_nowrap (s=0x70775ef8b000 "\b", 
    len=<optimized out>, len@entry=4, flags=flags@entry=16, fg=fg@entry=0, 
    bg=bg@entry=0, back=back@entry=0) at gui.c:2518
#2  0x000000000062a390 in gui_screenstr (fg=0, bg=0, back=0, flags=16, len=4, 
    off=0) at gui.c:2264
#3  gui_redraw_block (row1=<optimized out>, col1=<optimized out>, row2=62, 
    col2=<optimized out>, flags=flags@entry=16) at gui.c:2847
#4  0x000000000062b346 in gui_redraw_block (flags=16, col2=<optimized out>, 
    row2=<optimized out>, col1=<optimized out>, row1=<optimized out>)
    at gui.c:2714
#5  gui_redraw (x=<optimized out>, y=<optimized out>, w=<optimized out>, 
    h=<optimized out>) at gui.c:2719
#6  0x00000000006330e5 in expose_event (widget=<optimized out>, 
    event=0x7f7fffac3870, data=<optimized out>) at gui_gtk_x11.c:837
#7  0x000070775fd4220d in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#8  0x000070775e814c98 in g_closure_invoke ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#9  0x000070775e826626 in signal_emit_unlocked_R.isra.0 ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#10 0x000070775e827360 in signal_emit_valist_unlocked ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#11 0x000070775e82cf43 in g_signal_emit_valist ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#12 0x000070775e82d000 in g_signal_emit ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#13 0x000070775fe565dd in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#14 0x000070775fd411c0 in gtk_main_do_event ()
   from /usr/pkg/lib/libgtk-x11-2.0.so.0
#15 0x000070775f847f37 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#16 0x000070775f847ee1 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#17 0x000070775f847ee1 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#18 0x000070775f847ee1 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#19 0x000070775f843af7 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#20 0x000070775f844756 in gdk_window_process_updates ()
   from /usr/pkg/lib/libgdk-x11-2.0.so.0
#21 0x000070775fe643f7 in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#22 0x000070775e814c98 in g_closure_invoke ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#23 0x000070775e825f09 in signal_emit_unlocked_R.isra.0 ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#24 0x000070775e827a9d in signal_emit_valist_unlocked ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#25 0x000070775e82cf43 in g_signal_emit_valist ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#26 0x000070775e82d000 in g_signal_emit ()
   from /usr/pkg/lib/libgobject-2.0.so.0
#27 0x000070775fcc697c in ?? () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#28 0x000070775f822b51 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#29 0x000070775f052cf0 in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0
#30 0x000070775f055987 in g_main_context_iterate_unlocked.constprop ()
   from /usr/pkg/lib/libglib-2.0.so.0
#31 0x000070775f055efd in g_main_context_iteration ()
   from /usr/pkg/lib/libglib-2.0.so.0
#32 0x0000000000637552 in gui_mch_update () at gui_gtk_x11.c:6595
#33 0x000000000062ea62 in gui_start (arg=arg@entry=0x0) at gui.c:154
#34 0x000000000062ecb6 in ex_gui (eap=0x7f7fffac4530) at gui.c:4951
#35 0x000000000048a5a3 in do_one_cmd (cookie=<optimized out>, 
    fgetline=0x495ea4 <getexline>, cstack=0x7f7fffac46e0, flags=0, 
    cmdlinep=0x7f7fffac4490) at ex_docmd.c:2582
#36 do_cmdline (cmdline=cmdline@entry=0x0, fgetline=0x495ea4 <getexline>, 
    cookie=cookie@entry=0x0, flags=0) at ex_docmd.c:994
#37 0x00000000004ff26d in nv_colon (cap=0x7f7fffac4d90) at normal.c:3212
#38 0x0000000000505d5c in normal_cmd (oap=oap@entry=0x7f7fffac4e40, 
    toplevel=toplevel@entry=1) at normal.c:949
#39 0x000000000065d531 in main_loop (cmdwin=cmdwin@entry=0, 
    noexmode=noexmode@entry=0) at main.c:1562
#40 0x000000000065e742 in vim_main2 () at main.c:895
#41 0x00000000006691da in main (argc=<optimized out>, argv=<optimized out>)
    at main.c:441


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915538634@github.com>

Rhialto The M.

unread,
Jan 29, 2024, 4:08:08 PMJan 29
to vim/vim, Subscribed

So it is this loop that seems to be infinite:

5905         // Correct for differences in char width: some chars are
5906         // double-wide in 'encoding' but single-wide in utf-8.  Add a space to
5907         // compensate for that.
5908         for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen; )
5909         {
5910             plen = utf_ptr2len(bp);
5911             if ((*mb_ptr2cells)(sp) == 2 && utf_ptr2cells(bp) == 1)
5912             {
5913                 new_conv_buf = alloc(convlen + 2);
5914                 if (new_conv_buf == NULL)
5915                     return len;
5916                 plen += bp - conv_buf;
5917                 mch_memmove(new_conv_buf, conv_buf, plen);
5918                 new_conv_buf[plen] = ' ';
5919                 mch_memmove(new_conv_buf + plen + 1, conv_buf + plen,
5920                                                           convlen - plen + 1);
5921                 vim_free(conv_buf);
5922                 conv_buf = new_conv_buf;
5923                 ++convlen;
5924                 bp = conv_buf + plen;
5925                 plen = 1;
5926             }
5927             sp += (*mb_ptr2len)(sp);
5928             bp += plen;
5929         }
5930         s = conv_buf;
5931         len = convlen;
5932     }

When going through the loop, mb_ptr2len points to latin_ptr2len and since sp point to a NUL char, it returns 0 and sp doesn't increase.
A similar thing happens with bp and plen, which becomes 0 too and doesn't increase.
Hence there is no chance for the loop condition to become false --> endless loop.

bp and sp both point to a string "\b":

(gdb) print s
$30 = (char_u *) 0x70775ef8b000 "\b"
(gdb) print conv_buf
$31 = (char_u *) 0x70775e3ca060 "\b"

I'm not sure why it's trying to print a backspace... but it shouldn't loop like this.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915569407@github.com>

Rhialto The M.

unread,
Jan 29, 2024, 4:13:25 PMJan 29
to vim/vim, Subscribed

This seems to fix the issue for my case, but I'm not sure this isn't just papering over some other logic error. This loop, surely, terminated once upon a time, I would expect...

diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c
index 187123739..a1b66fe26 100644
--- a/src/gui_gtk_x11.c
+++ b/src/gui_gtk_x11.c
@@ -5905,7 +5905,7 @@ gui_gtk2_draw_string(int row, int col, char_u *s, int len, int flags)
        // Correct for differences in char width: some chars are
        // double-wide in 'encoding' but single-wide in utf-8.  Add a space to
        // compensate for that.
-       for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen; )
+       for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen && *sp && *bp; )
        {
            plen = utf_ptr2len(bp);
            if ((*mb_ptr2cells)(sp) == 2 && utf_ptr2cells(bp) == 1)


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915579811@github.com>

Christian Brabandt

unread,
Jan 29, 2024, 4:15:12 PMJan 29
to vim/vim, Subscribed

are you using latin1 encoding? What is your encoding option set to?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915582502@github.com>

Rhialto The M.

unread,
Jan 29, 2024, 4:17:30 PMJan 29
to vim/vim, Subscribed

Yes, I use latin1 encoding. It was good enough (even hyper-modern) for Vim on my Amiga, it's good enough now :)


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915586777@github.com>

Rhialto The M.

unread,
Jan 29, 2024, 4:55:38 PMJan 29
to vim/vim, Subscribed

I added some debugging output:

diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c
index 187123739..d1dda26df 100644
--- a/src/gui_gtk_x11.c
+++ b/src/gui_gtk_x11.c
@@ -5900,14 +5900,16 @@ gui_gtk2_draw_string(int row, int col, char_u *s, int len, int flags)
         */
        convlen = len;
        conv_buf = string_convert(&output_conv, s, &convlen);
+       fprintf(stderr, "***len = %d, conv_len = %d s[0]=%d s[1]=%d s[2]=%d ****\n", len, convlen, s[0], s[1], s[2]);
        g_return_val_if_fail(conv_buf != NULL, len);
 
        // Correct for differences in char width: some chars are
        // double-wide in 'encoding' but single-wide in utf-8.  Add a space to
        // compensate for that.
-       for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen; )
+       for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen /*&& *sp && *bp*/; )
        {
            plen = utf_ptr2len(bp);
+           fprintf(stderr, "***plen = %d, *bp = %d ****\n", plen, *bp);
            if ((*mb_ptr2cells)(sp) == 2 && utf_ptr2cells(bp) == 1)
            {
                new_conv_buf = alloc(convlen + 2);
@@ -5926,6 +5928,9 @@ gui_gtk2_draw_string(int row, int col, char_u *s, int len, int flags)
            }
            sp += (*mb_ptr2len)(sp);
            bp += plen;
+           fprintf(stderr, "***sp = s+%d, bp = conv_buf+%d ****\n", sp -s, bp - conv_buf);
+           //sleep(1);
+           while (plen == 0) ;
        }
        s = conv_buf;
        len = convlen;

and the result is this:

.../vim/vim/src$ ./vim --clean Makefile
...
***len = 1, conv_len = 1 s[0]=35 s[1]=32 s[2]=77 ****
***plen = 1, *bp = 35 ****
***sp = s+1, bp = conv_buf+1 ****
***len = 1, conv_len = 1 s[0]=35 s[1]=32 s[2]=77 ****
***plen = 1, *bp = 35 ****
***sp = s+1, bp = conv_buf+1 ****
***len = 1, conv_len = 1 s[0]=35 s[1]=32 s[2]=77 ****
***plen = 1, *bp = 35 ****
***sp = s+1, bp = conv_buf+1 ****
***len = 164, conv_len = 192 s[0]=8 s[1]=0 s[2]=0 ****
***plen = 1, *bp = 8 ****
***sp = s+1, bp = conv_buf+1 ****
***plen = 0, *bp = 0 ****
***sp = s+1, bp = conv_buf+1 ****

and then it is hanging in that infinite loop 1while plen == 0. The strange thing is that it just has been printed that len = 183, conv_len = 224but the corresponding string is just the backspace 8 and NUL.? It smells like strings` gets corrupted somewhere.

Also during one of my attempts it actually worked correctly, but the next attempt failed again.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1915641256@github.com>

Rhialto The M.

unread,
Jan 30, 2024, 4:36:58 PMJan 30
to vim/vim, Subscribed

I spent a few hours looking at this again. I tried to reproduce it on my laptop with Fedora. No luck. I tried to compile it with sanitizers on NetBSD. That gave a segfault instead of a nice error message. So I had to do without

I arranged to sleep the child process after the fork(), so I could attach gdb to it. I used a hardware watchpoint, to watch ScreenLines[0] changing. We were editing the vim src/Makefile, which begins with #.

(gdb) watch ScreenLines[0]
Thread 1 "" hit Hardware watchpoint 1: ScreenLines[0]

(gdb) c
Continuing.
[New LWP 2 of process 20508]
[New LWP 4 of process 20508]
[New LWP 3 of process 20508]
[New LWP 6 of process 20508]
[New LWP 5 of process 20508]
[New LWP 8 of process 20508]
[New LWP 7 of process 20508]
[New LWP 10 of process 20508]
[New LWP 9 of process 20508]
[New LWP 11 of process 20508]
[New LWP 12 of process 20508]

Thread 1 "" hit Hardware watchpoint 1: ScreenLines[0]

Old value = 35 '#'
New value = <unreadable>
free_screenlines () at screen.c:2750
2750        VIM_CLEAR(ScreenAttrs);

(gdb) print ScreenLines
$1 = (schar_T *) 0x0
(gdb) bt
#0  free_screenlines () at screen.c:2729
#1  0x0000000000576e55 in screenalloc (doclear=doclear@entry=1)
    at screen.c:2646
#2  0x000000000057737e in screen_valid (doclear=doclear@entry=1)
    at screen.c:2347
#3  0x00000000004fa79c in update_topline () at move.c:288
#4  0x00000000004fae63 in curs_columns (may_scroll=may_scroll@entry=1)
    at move.c:1132
#5  0x00000000004fb5fa in validate_cursor () at move.c:827
#6  0x000000000061e9e6 in win_new_height (wp=0x7499700d6000, height=62)
    at window.c:6955
#7  0x000000000061ea22 in frame_new_height (topfrp=0x74997013e040, 
    height=height@entry=62, topfirst=topfirst@entry=0, wfh=wfh@entry=1)
    at window.c:3701
#8  0x0000000000620b8b in shell_new_rows () at window.c:5943
#9  0x00000000005bc5a3 in win_new_shellsize () at term.c:3609
#10 0x000000000062e323 in gui_init () at gui.c:773
#11 0x00000000005be223 in set_termname (term=0x74996f1656b8 "gui")
    at term.c:2092
#12 0x00000000005be922 in termcapinit (name=name@entry=0x696c52 "builtin_gui")
    at term.c:2717
#13 0x000000000062eace in gui_attempt_start () at gui.c:184
#14 0x000000000062ed7d in gui_do_fork () at gui.c:322
#15 gui_start (arg=arg@entry=0x0) at gui.c:97
#16 0x000000000062ee37 in ex_gui (eap=0x7f7fff89a720) at gui.c:4957
#17 0x000000000048a593 in do_one_cmd (cookie=<optimized out>, 
    fgetline=0x495e94 <getexline>, cstack=0x7f7fff89a8d0, flags=0, 
    cmdlinep=0x7f7fff89a680) at ex_docmd.c:2582
#18 do_cmdline (cmdline=cmdline@entry=0x0, fgetline=0x495e94 <getexline>, 
    cookie=cookie@entry=0x0, flags=0) at ex_docmd.c:994
#19 0x00000000004ff26d in nv_colon (cap=0x7f7fff89af80) at normal.c:3212
#20 0x0000000000505d5c in normal_cmd (oap=oap@entry=0x7f7fff89b030, 
    toplevel=toplevel@entry=1) at normal.c:949
#21 0x000000000065d731 in main_loop (cmdwin=cmdwin@entry=0, 
    noexmode=noexmode@entry=0) at main.c:1562
#22 0x000000000065e942 in vim_main2 () at main.c:895
#23 0x00000000006693da in main (argc=<optimized out>, argv=<optimized out>)
    at main.c:441

The caller at screen.c:2646 will soon assign newScreenLines to ScreenLines.

2646        free_screenlines();
(gdb) print new_ScreenLines
$2 = (schar_T *) 0x74996dc5c000 "\b"

and there we have our backspace...

so the problem is likely to be in the initialization of new_ScreenLines in
screen.c:screenalloc().

Let's add lots and lots of conditional print statements to catch it...
Output:

screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=84, Columns=183
screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=85, Columns=183
screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=86, Columns=183
screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=87, Columns=183
screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=88, Columns=183
screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=89, Columns=183
gui_outstr_nowrap 2320: row=0 col=0 len=1 s[0]=35 s[1]=32 s[2]=77
gui_outstr_nowrap 2518: row=0 col=0 len=1 s[0]=35 s[1]=32 s[2]=77
***len = 1, conv_len = 1 s[0]=35 s[1]=32 s[2]=77 ****
***plen = 1, *bp = 35 ****
***sp = s+1, bp = conv_buf+1 ****
gui_redraw_block: row 0->0, col 0->0, off=0 idx(len)=1 SL[0]=35 SL[1]=32 SL[2]=77
gui_screenstr 2320: off=0 len=1 s[0]=35 s[1]=32 s[2]=77 '#'
gui_outstr_nowrap 2320: row=0 col=0 len=1 s[0]=35 s[1]=32 s[2]=77
gui_outstr_nowrap 2518: row=0 col=0 len=1 s[0]=35 s[1]=32 s[2]=77
***len = 1, conv_len = 1 s[0]=35 s[1]=32 s[2]=77 ****
***plen = 1, *bp = 35 ****
***sp = s+1, bp = conv_buf+1 ****
gui_outstr_nowrap 2320: row=0 col=0 len=1 s[0]=35 s[1]=32 s[2]=77
gui_outstr_nowrap 2518: row=0 col=0 len=1 s[0]=35 s[1]=32 s[2]=77
***len = 1, conv_len = 1 s[0]=35 s[1]=32 s[2]=77 ****
***plen = 1, *bp = 35 ****
***sp = s+1, bp = conv_buf+1 ****
screenalloc 2653: new_ScreenLines[0] = 8... new_row=0
screenalloc 2653: new_ScreenLines[0] = 8... new_row=1
screenalloc 2653: new_ScreenLines[0] = 8... new_row=2
screenalloc 2653: new_ScreenLines[0] = 8... new_row=3
screenalloc 2653: new_ScreenLines[0] = 8... new_row=4

Doesn't this suggest that there is drawing to the window going on while
screenalloc() is manipulating the screen memory? Shouldn't there be a lock on
that? There are rather a lot of threads shown by gdb (at the top). The fact that I don't see an expose event logged, but do see gui_redraw_block: row 0->0, col 0->0, suggests that it is the cursor being drawn or erased.

This may even be separate from the corruption in new_ScreenLines??

What is weird that there is clearly first a loop up to 89 rows to fill the new screen with spaces, and then another loop starting at 0 again which detects the corrupted value immediately... but the source code is showing only one loop... Either the optimizer is splitting one loop into two... or there are 2 threads here, mixing their output?

So for the moment I have at least as many new questions as I got answers...


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12671/1917935092@github.com>

Rhialto The M.

unread,
Jan 30, 2024, 4:39:22 PMJan 30