[vim/vim] GVim UI freezes (Issue #12671)
Vít Ondruch
Steps to reproduce
- Open some file in GVim from terminal, in my case it might be
$ gvim rubygem-excon.spec - Do something else in some other windows, typically switch to browser or terminal
- 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.
- 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.
Vít Ondruch
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.
Vít Ondruch
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.
Christian Brabandt
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.
Vít Ondruch
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.
VZ
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.
VZ
Some more information:
- The problem is reproducible in the latest master i.e. v9.0.1677.
- 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. - 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.
Vít Ondruch
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.
Jesse Pavel
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.
Vít Ondruch
I've hit a similar problem on ChromeOS using gvim, and it turned out if I did a
let &guifont = &guifontit 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.
Vít Ondruch
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.
Jesse Pavel
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.
Vít Ondruch
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.
Vít Ondruch
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.
VZ
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.
Vít Ondruch
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.
VZ
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.
Vít Ondruch
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.
sfome
i got the same error on fedora 38
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rom888
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.
sfome
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.
Rom888
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
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.
Vít Ondruch
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.
sfome
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.
Capmus Banon
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.
Rhialto The M.
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.
Rhialto The M.
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.
Rhialto The M.
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.
Rhialto The M.
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.
Christian Brabandt
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.
Rhialto The M.
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.
Rhialto The M.
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.
Rhialto The M.
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.
Rhialto The M.
The modified code going with the above:
2567 for (new_row = 0; new_row < Rows; ++new_row)
2568 {
2569 new_LineOffset[new_row] = new_row * Columns;
2570 new_LineWraps[new_row] = FALSE;
2571
2572 /*
2573 * If the screen is not going to be cleared, copy as much as
2574 * possible from the old screen to the new one and clear the rest
2575 * (used when resizing the window at the "--more--" prompt or when
2576 * executing an external command, for the GUI).
2577 */
2578 if (!doclear)
2579 {
2580 fprintf(stderr, "screenalloc 2580: !doclear, vim_memset(new_ScreenLines with spaces, new_row=%d, Columns=%d\n", new_row, Columns);
2581 (void)vim_memset(new_ScreenLines + new_row * Columns,
2582 ' ', (size_t)Columns * sizeof(schar_T));
2583 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2583: new_ScreenLines[0] = 8...\n"); }
2584 if (enc_utf8)
2585 {
2586 (void)vim_memset(new_ScreenLinesUC + new_row * Columns,
2587 0, (size_t)Columns * sizeof(u8char_T));
2588 for (int i = 0; i < p_mco; ++i)
2589 (void)vim_memset(new_ScreenLinesC[i]
2590 + new_row * Columns,
2591 0, (size_t)Columns * sizeof(u8char_T));
2592 }
2593 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2593: new_ScreenLines[0] = 8...\n"); }
2594 if (enc_dbcs == DBCS_JPNU)
2595 (void)vim_memset(new_ScreenLines2 + new_row * Columns,
2596 0, (size_t)Columns * sizeof(schar_T));
2597 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2597: new_ScreenLines[0] = 8...\n"); }
2598 (void)vim_memset(new_ScreenAttrs + new_row * Columns,
2599 0, (size_t)Columns * sizeof(sattr_T));
2600 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2600: new_ScreenLines[0] = 8...\n"); }
2601 (void)vim_memset(new_ScreenCols + new_row * Columns,
2602 0, (size_t)Columns * sizeof(colnr_T));
2603 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2603: new_ScreenLines[0] = 8...\n"); }
2604 old_row = new_row + (screen_Rows - Rows);
2605 if (old_row >= 0 && ScreenLines != NULL)
2606 {
2607 if (screen_Columns < Columns)
2608 len = screen_Columns;
2609 else
2610 len = Columns;
2611 // When switching to utf-8 don't copy characters, they
2612 // may be invalid now. Also when p_mco changes.
2613 if (!(enc_utf8 && ScreenLinesUC == NULL)
2614 && p_mco == Screen_mco) {
2615 fprintf(stderr, "screenalloc 2610: mch_memmove(new_ScreenLines !enc_utf8 to=%d from=%d len=%d\n", new_LineOffset[new_row], LineOffset[old_row], (int)(len * sizeof(schar_T)));
2616 mch_memmove(new_ScreenLines + new_LineOffset[new_row],
2617 ScreenLines + LineOffset[old_row],
2618 (size_t)len * sizeof(schar_T));
2619 }
2620 if (enc_utf8 && ScreenLinesUC != NULL
2621 && p_mco == Screen_mco)
2622 {
2623 fprintf(stderr, "screenalloc 2618: mch_memmove(new_ScreenLinesUC enc_utf8 to=%d from=%d len=%d\n", new_LineOffset[new_row], LineOffset[old_row], (int)(len * sizeof(schar_T)));
2624 mch_memmove(new_ScreenLinesUC + new_LineOffset[new_row],
2625 ScreenLinesUC + LineOffset[old_row],
2626 (size_t)len * sizeof(u8char_T));
2627 for (int i = 0; i < p_mco; ++i) {
2628 mch_memmove(new_ScreenLinesC[i]
2629 + new_LineOffset[new_row],
2630 ScreenLinesC[i] + LineOffset[old_row],
2631 (size_t)len * sizeof(u8char_T));
2632 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2632: new_ScreenLines[0] = 8...\n"); }
2633 }
2634 }
2635 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2635: new_ScreenLines[0] = 8...\n"); }
2636 if (enc_dbcs == DBCS_JPNU && ScreenLines2 != NULL) {
2637 fprintf(stderr, "screenalloc 2629: mch_memmove(new_ScreenLines2 enc_utf8 to=%d from=%d len=%d\n", new_LineOffset[new_row], LineOffset[old_row], (int)(len * sizeof(schar_T)));
2638 mch_memmove(new_ScreenLines2 + new_LineOffset[new_row],
2639 ScreenLines2 + LineOffset[old_row],
2640 (size_t)len * sizeof(schar_T));
2641 }
2642 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2642: new_ScreenLines[0] = 8...\n"); }
2643 mch_memmove(new_ScreenAttrs + new_LineOffset[new_row],
2644 ScreenAttrs + LineOffset[old_row],
2645 (size_t)len * sizeof(sattr_T));
2646 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2646: new_ScreenLines[0] = 8...\n"); }
2647 mch_memmove(new_ScreenCols + new_LineOffset[new_row],
2648 ScreenAttrs + LineOffset[old_row],
2649 (size_t)len * sizeof(colnr_T));
2650 }
2651 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2651: new_ScreenLines[0] = 8...\n"); }
2652 }
2653 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2653: new_ScreenLines[0] = 8... new_row=%d\n", new_row); }
2654 }
2655 // Use the last line of the screen for the current line.
2656 current_ScreenLine = new_ScreenLines + Rows * Columns;
2657
2658 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2658: new_ScreenLines[0] = 8...\n"); }
2659 #ifdef FEAT_PROP_POPUP
2660 vim_memset(new_popup_mask, 0, Rows * Columns * sizeof(short));
2661 vim_memset(new_popup_transparent, 0, Rows * Columns * sizeof(char));
2662 #endif
2663 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2663: new_ScreenLines[0] = 8...\n"); }
2664 }
2665
2666 if (new_ScreenLines[0] == 8) { fprintf(stderr, "screenalloc 2666: new_ScreenLines[0] = 8...\n"); }
2667 free_screenlines();
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.