[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.
Rhialto The M.
I tried compiling screen.c with -O0 and it seemed like the bug didn't happen every time any more (but still most of the time).
Also, this part of the 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
appears first. Then my window manager (ctwm) puts up the outline of the window to open. When I click to do that, the output continues. It is probably a hint for something but I don't know what, yet...
Tomorrow is another day.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Oh, it's simply that screenalloc is called all the time instead of just the once. If it detects no screen size it returns quickly.
screenalloc 2391 before retry
screenalloc 2393 after retry
screenalloc 2411 actual resizing
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
this shows that screenalloc can do the resizing, and then somehow skip over all options to fill in new_ScreenLines and leave it uninitialized. Probably when doclear is false.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
So where are we? It seems that calling screenalloc(TRUE) is meant for
situations where the caller is going to completely re-fill the screen
memory soon. So as an optimization, screenalloc() can leave
ScreenLines uninitialized. That kind of follows from the comment (for
the opposite case) "If the screen is not going to be cleared, copy as
much as possible from the old screen to the new one and clear the rest"
However in this case, something (possibly a cursor update) is trying to
render the screen memory to the GUI before ScreenLines are filled
again.
So at least two ways to fix this present themselves.
- find the place where this duty to initialize ScreenLines is broken
- simply always initialize ScreenLines with something.
For method 1, we need to find where the problem is. Going up the call
stack from comment #12671 (comment) we end up at call frame 3:
#2 0x000000000057737e in screen_valid (doclear=doclear@entry=1)
at screen.c:2347
#3 0x00000000004fa79c in update_topline () at move.c:288
In update_topline(), I see nothing that indicates any awareness of the
urgency to fill ScreenLines as soon as possible. In fact, neither do
most of the other occurrences of screen_valid(TRUE). Except in
screen_ins_lines() where there is a comment "Don't update the GUI
cursor here, ScreenLines[] is invalid until the scrolling is actually
carried out."
So at this point my assumption that we're having an optimization,
with rare cases of bugginess, is shifting towards "just plain bug,
period".
So I propose to fix this issue by taking the code that fills
ScreenLines with spaces out of the condition !doclear. The same for
ScreenLines2 and the other related arrays.
diff --git a/src/screen.c b/src/screen.c
index 032e447a9..ea2eaa587 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -2569,6 +2569,24 @@ give_up:
new_LineOffset[new_row] = new_row * Columns;
new_LineWraps[new_row] = FALSE;
+ (void)vim_memset(new_ScreenLines + new_row * Columns,
+ ' ', (size_t)Columns * sizeof(schar_T));
+ if (enc_utf8)
+ {
+ (void)vim_memset(new_ScreenLinesUC + new_row * Columns,
+ 0, (size_t)Columns * sizeof(u8char_T));
+ for (int i = 0; i < p_mco; ++i)
+ (void)vim_memset(new_ScreenLinesC[i]
+ + new_row * Columns,
+ 0, (size_t)Columns * sizeof(u8char_T));
+ }
+ if (enc_dbcs == DBCS_JPNU)
+ (void)vim_memset(new_ScreenLines2 + new_row * Columns,
+ 0, (size_t)Columns * sizeof(schar_T));
+ (void)vim_memset(new_ScreenAttrs + new_row * Columns,
+ 0, (size_t)Columns * sizeof(sattr_T));
+ (void)vim_memset(new_ScreenCols + new_row * Columns,
+ 0, (size_t)Columns * sizeof(colnr_T));
/*
* If the screen is not going to be cleared, copy as much as
* possible from the old screen to the new one and clear the rest
@@ -2577,24 +2595,6 @@ give_up:
*/
if (!doclear)
{
- (void)vim_memset(new_ScreenLines + new_row * Columns,
- ' ', (size_t)Columns * sizeof(schar_T));
- if (enc_utf8)
- {
- (void)vim_memset(new_ScreenLinesUC + new_row * Columns,
- 0, (size_t)Columns * sizeof(u8char_T));
- for (int i = 0; i < p_mco; ++i)
- (void)vim_memset(new_ScreenLinesC[i]
- + new_row * Columns,
- 0, (size_t)Columns * sizeof(u8char_T));
- }
- if (enc_dbcs == DBCS_JPNU)
- (void)vim_memset(new_ScreenLines2 + new_row * Columns,
- 0, (size_t)Columns * sizeof(schar_T));
- (void)vim_memset(new_ScreenAttrs + new_row * Columns,
- 0, (size_t)Columns * sizeof(sattr_T));
- (void)vim_memset(new_ScreenCols + new_row * Columns,
- 0, (size_t)Columns * sizeof(colnr_T));
old_row = new_row + (screen_Rows - Rows);
if (old_row >= 0 && ScreenLines != NULL)
{
The diff looks bigger than it is because the lines are un-indented one
step. Effectively, the condition if (!doclear) is just moved some
lines down.
Smell test analysis: checking doclear and filling the screen with
spaces when set makes perfect sense: it clear the screen, as requested.
Looking at it this way makes the previous state clearly a bug.
Having found this patch, it seems not so likely that it was actually the same issue as the OP...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
According to git blame, that particular code comes from 071d427 which is almost 20 years ago. I am not saying there is not a bug, but I would find it surprising, if no-one noticed before. Are you sure it is not a compiler bug or something similar obscure?
for (sp = s, bp = conv_buf; sp < s + len && bp < conv_buf + convlen && *sp && *bp; )
I suppose if we break out of the loop early, we should also update len so that we do not run into the same situation further down?
Yes, I use latin1 encoding. It was good enough (even hyper-modern) for Vim on my Amiga, it's good enough now :)
I assume you are using a utf-8 locale in your terminal (or in 'termencoding')?
Well, perhaps make the switch to use utf-8 instead so that Vim wouldn't try to run into that conversion loop at all 🤷
(I just noticed your new comment, haven't had a chance to read through it yet...)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Nope, I do not use an utf-8 locale, or terminal:
.../vim/vim/src$ locale
LANG=""
LC_CTYPE="nl_NL.ISO8859-1"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=""
Entering Ex mode. Type "visual" to go to Normal mode.
:set encoding?
encoding=latin1
:set fencs?
fileencodings=latin1,ucs-bom,utf-8
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
and what is :set termencoding?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Oh, that particular loop may be 20 years old - something much have changed more recently to break it. But I've been using latin1 for more like 30 years. And the :gui command, worked for most of that time. I don't use it super-often, so that's why I only noticed recently that it broke.
termencoding is unset:
:set termencoding?
termencoding=
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
hm, okay. Not sure then why gvim wants to convert the s buffer 🤷
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
As soon as the GUI is up, termencoding=utf-8. I don't think that is something I set, but just a property of the GUI...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Hm, can you create a PR for this patch? It's just some memset() calls, so it seems reasonable safe. Can you run with your patch for a while and verify you have fixed the problem?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Sure, will do. I'll also try to see if I can bisect it, I'm curious...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
ah, that makes sense. This is a fix for CVE-2022-2849
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
Just applied the fd47265 and lets see if it by a chance helps my case. I wish there was "good starting" point such as infinite loop.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
Just applied the fd47265 and lets see if it by a chance helps my case. I wish there was "good" starting point such as infinite loop.
No luck, although I'd say it behaves slightly different. Let me share this screenshot:
Snimek.obrazovky.z.2024-02-02.16-02-01.png (view on web)
This is result of resizing the window. Unfortunately, it is not visible, but there actually is also painting outside of the windows itself. Moving around the document, the content outside of the editing are changes slightly. What is actually correctly displayed during resizing is the actual size. Let me share the video, but it does not precisely represent what is displayed on the screen:
Záznam obrazovky z 2024-02-02 16-06-58.webm
But the black rectangle, which is extending out of the window content roughly represents the behavior I observe.
—
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 think that at some point, I should hit the screenalloc and move somewhere at https://github.com/vim/vim/blob/fa37835b8c0ed0f83952978fca4c332335ca7c46/src/screen.c#L2413
But that does not happen it seems.
I wonder what is actually some call back which should react to the window resizing event?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
@voxik Interesting what changes you see. I would suppose that whatever your bug exactly is, it would behave more consistently now (since it seems that the contents of ScreenLines matter to it).
For a resize event, you're using Wayland (which I don't) which probably means gtk3, right? I browsed the source a bit and I expect that form_configure_event() in gui_gtk_x11.c might be what you're looking for, despite the x11 in the name.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
@voxik Interesting what changes you see. I would suppose that whatever your bug exactly is, it would behave more consistently now (since it seems that the contents of ScreenLines matter to it).
I assume, that if I change the window size, something in this condition should evaluate to false:
https://github.com/vim/vim/blob/fa37835b8c0ed0f83952978fca4c332335ca7c46/src/screen.c#L2397-L2406
But that does not happen 🤷
For a resize event, you're using Wayland (which I don't) which probably means gtk3, right? I browsed the source a bit and I expect that
form_configure_event()ingui_gtk_x11.cmight be what you're looking for, despite the x11 in the name.
Thx, yes, that seems plausible. Actually I have a breakpoint on that function already, but I cannot trigger it in the "frozen" state. Checking with healthy window, I can indeed hit that breakpoint after resize
—
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 have already had the idea previously, but I am back to suspect that it has something with forking. Gvim getting focus, two processes are forked (have to explore why, I think git-gutter is one reason). Not expert here, but if there is done some cleanup somewhere, I suspect it could cause issues.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Pavol Babinčák
Just applied the fd47265 and lets see if it by a chance helps my case. I wish there was "good" starting point such as infinite loop.
No luck, although I'd say it behaves slightly different. Let me share this screenshot:
This is result of resizing the window. Unfortunately, it is not visible, but there actually is also painting outside of the windows itself. Moving around the document, the content outside of the editing are changes slightly. What is actually correctly displayed during resizing is the actual size.
I have seen these artifacts for past a week or so since I started to use gvim. I'm running Fedora packages of version 9.1.031-1.fc39. Admittedly I haven't used gvim for last half a year or so to avoid this (#12671) bug.
—
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 have already had the idea previously, but I am back to suspect that it has something with forking. Gvim getting focus, two processes are forked (have to explore why, I think git-gutter is one reason). Not expert here, but if there is done some cleanup somewhere, I suspect it could cause issues.
No, I have removed gitgutter and the forking with it. But it still happens. I am clue less where to start 🤷
—
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 have decided to also report this against GTK, because it seems that when running in Wayland session, GVim works mostly 1 fine:
https://gitlab.gnome.org/GNOME/gtk/-/issues/6441
Footnotes
-
With exception of messages like:
(gvim:640038): GLib-GObject-CRITICAL **: 18:00:21.001: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Gdk-Message: 18:00:21.089: Unable to load sb_v_double_arrow from the cursor theme ↩
—
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
Just stumbled upon #12070, where the same symptoms are described
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
brockn8r
FWIW: Whenever I encounter these strange GUI issues, I go old-school as a work-around while you smart people figure out how to fix things. By old-school, I mean making use of xterm. I add something like the following to my bashrc:
alias vi='function _vifunc(){ xterm -e "gvim $1"; };_vifunc'
So far, this does not require me to wait an eternity while the gvim window unfreezes. Hope it helps.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
After a trying e.g. Valgrind, I am back in debugger with a few more ideas.
So there is the configure-event signal, which should be emitted upon size, position or stacking of the widget 's window changes:
This calls drawarea_configure_event_cb function. Setting breakpoint there, this is the backtrace:
Thread 1 "gvim" hit Breakpoint 1, drawarea_configure_event_cb (widget=widget@entry=0x555555fa8060, event=0x555556422530, data=0x0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:2980
2980 {
(gdb) bt
#0 drawarea_configure_event_cb (widget=widget@entry=0x555555fa8060, event=0x555556422530, data=0x0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:2980
#1 0x00007ffff768d5f4 in _gtk_marshal_BOOLEAN__BOXED (closure=0x555555fa8600, return_value=0x7fffffffb340, param_values=0x7fffffffb3d0, marshal_data=<optimized out>, invocation_hint=<optimized out>, n_param_values=<optimized out>)
at gtk/gtkmarshalers.c:84
#2 0x00007ffff7dce4da in g_closure_invoke (closure=0x555555fa8600, return_value=0x7fffffffb340, n_param_values=2, param_values=0x7fffffffb3d0, invocation_hint=0x7fffffffb320) at ../gobject/gclosure.c:834
#3 0x00007ffff7dfd903 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffb4d0, detail=detail@entry=0, instance=instance@entry=0x555555fa8060, emission_return=emission_return@entry=0x7fffffffb550,
instance_and_params=instance_and_params@entry=0x7fffffffb3d0) at ../gobject/gsignal.c:3879
#4 0x00007ffff7dedeb9 in signal_emit_valist_unlocked (instance=instance@entry=0x555555fa8060, signal_id=signal_id@entry=72, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffb640) at ../gobject/gsignal.c:3524
#5 0x00007ffff7dee8b1 in g_signal_emit_valist (instance=0x555555fa8060, signal_id=72, detail=0, var_args=var_args@entry=0x7fffffffb640) at ../gobject/gsignal.c:3254
#6 0x00007ffff7dee973 in g_signal_emit (instance=instance@entry=0x555555fa8060, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574
#7 0x00007ffff795d314 in gtk_widget_event_internal.part.0.lto_priv.0 (widget=0x555555fa8060, event=0x555556422530) at ../gtk/gtkwidget.c:7812
#8 0x00007ffff77517e0 in gtk_drawing_area_send_configure (darea=0x555555fa8060) at ../gtk/gtkdrawingarea.c:264
#9 0x00007ffff794c4b7 in gtk_widget_size_allocate_with_baseline (widget=0x555555fa8060, allocation=allocation@entry=0x7fffffffb8a0, baseline=<optimized out>, baseline@entry=-1) at ../gtk/gtkwidget.c:6179
#10 0x00007ffff794c80e in gtk_widget_size_allocate (widget=<optimized out>, allocation=allocation@entry=0x7fffffffb8a0) at ../gtk/gtkwidget.c:6260
#11 0x00005555558508ff in form_position_child (form=<optimized out>, child=0x555555fa70a0, force_allocate=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_f.c:805
#12 0x00005555558b0a2a in gui_gtk_form_move_resize (h=840, w=1700, y=0, x=0, widget=0x555555fa8060, form=0x555555fa79a0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_f.c:840
#13 gui_mch_set_text_area_pos (y=0, h=840, w=1700, x=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk.c:845
#14 gui_position_components.isra.0 (total_width=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:1464
#15 0x0000555555846312 in gui_resize_shell (pixel_width=1716, pixel_height=841) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:1579
#16 0x0000555555850c0d in gui_resize_shell (pixel_height=841, pixel_width=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:1557
#17 form_configure_event (widget=widget@entry=0x555555fa79a0, event=0x7fffffffc070, data=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:4317
#18 0x00007ffff768d5f4 in _gtk_marshal_BOOLEAN__BOXED (closure=0x5555561631b0, return_value=0x7fffffffbb50, param_values=0x7fffffffbbe0, marshal_data=<optimized out>, invocation_hint=<optimized out>, n_param_values=<optimized out>)
at gtk/gtkmarshalers.c:84
#19 0x00007ffff7dce4da in g_closure_invoke (closure=0x5555561631b0, return_value=0x7fffffffbb50, n_param_values=2, param_values=0x7fffffffbbe0, invocation_hint=0x7fffffffbb30) at ../gobject/gclosure.c:834
#20 0x00007ffff7dfd903 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffbce0, detail=detail@entry=0, instance=instance@entry=0x555555fa79a0, emission_return=emission_return@entry=0x7fffffffbd60,
instance_and_params=instance_and_params@entry=0x7fffffffbbe0) at ../gobject/gsignal.c:3879
#21 0x00007ffff7dedeb9 in signal_emit_valist_unlocked (instance=instance@entry=0x555555fa79a0, signal_id=signal_id@entry=72, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffbe50) at ../gobject/gsignal.c:3524
#22 0x00007ffff7dee8b1 in g_signal_emit_valist (instance=0x555555fa79a0, signal_id=72, detail=0, var_args=var_args@entry=0x7fffffffbe50) at ../gobject/gsignal.c:3254
#23 0x00007ffff7dee973 in g_signal_emit (instance=instance@entry=0x555555fa79a0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574
#24 0x00007ffff795d314 in gtk_widget_event_internal.part.0.lto_priv.0 (widget=0x555555fa79a0, event=0x7fffffffc070) at ../gtk/gtkwidget.c:7812
#25 0x00007ffff77f3f9c in gtk_main_do_event (event=<optimized out>) at ../gtk/gtkmain.c:1861
#26 gtk_main_do_event (event=<optimized out>) at ../gtk/gtkmain.c:1691
#27 0x0000555555850d75 in form_send_configure (form=0x555555fa79a0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_f.c:860
#28 form_size_allocate (widget=0x555555fa79a0, allocation=0x7fffffffc160) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_f.c:520
#29 0x00007ffff794c4b7 in gtk_widget_size_allocate_with_baseline (widget=0x555555fa79a0, allocation=<optimized out>, baseline=<optimized out>) at ../gtk/gtkwidget.c:6179
#30 0x00007ffff76bef15 in gtk_box_size_allocate_no_center (widget=<optimized out>, allocation=<optimized out>) at ../gtk/gtkbox.c:817
#31 0x00007ffff76bfdad in gtk_box_allocate_contents (gadget=<optimized out>, allocation=<optimized out>, baseline=<optimized out>, out_clip=0x7fffffffc360, unused=<optimized out>) at ../gtk/gtkbox.c:1211
#32 0x00007ffff771865e in gtk_css_gadget_allocate (gadget=0x555555f8e530, allocation=0x7fffffffc4d0, baseline=-1, out_clip=0x7fffffffc400) at ../gtk/gtkcssgadget.c:790
#33 0x00007ffff76bdb0c in gtk_box_size_allocate (widget=0x555555f8dbd0, allocation=0x7fffffffc4d0) at ../gtk/gtkbox.c:1225
#34 0x00007ffff794c4b7 in gtk_widget_size_allocate_with_baseline (widget=0x555555f8dbd0, allocation=<optimized out>, baseline=<optimized out>) at ../gtk/gtkwidget.c:6179
#35 0x00007ffff796c48b in gtk_window_size_allocate (widget=0x555555b7f5d0, allocation=<optimized out>) at ../gtk/gtkwindow.c:7957
#36 0x00007ffff7dce4da in g_closure_invoke (closure=0x5555559f27d0, return_value=0x0, n_param_values=2, param_values=0x7fffffffc760, invocation_hint=0x7fffffffc6b0) at ../gobject/gclosure.c:834
#37 0x00007ffff7dfda30 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffc860, detail=detail@entry=0, instance=instance@entry=0x555555b7f5d0, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffc760) at ../gobject/gsignal.c:3712
#38 0x00007ffff7dee654 in signal_emit_valist_unlocked (instance=instance@entry=0x555555b7f5d0, signal_id=signal_id@entry=42, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffc9d0) at ../gobject/gsignal.c:3511
#39 0x00007ffff7dee8b1 in g_signal_emit_valist (instance=0x555555b7f5d0, signal_id=42, detail=0, var_args=var_args@entry=0x7fffffffc9d0) at ../gobject/gsignal.c:3254
#40 0x00007ffff7dee973 in g_signal_emit (instance=instance@entry=0x555555b7f5d0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574
#41 0x00007ffff794c696 in gtk_widget_size_allocate_with_baseline (widget=0x555555b7f5d0, allocation=<optimized out>, baseline=<optimized out>) at ../gtk/gtkwidget.c:6177
#42 0x00007ffff796d8f7 in gtk_window_move_resize (window=0x555555b7f5d0) at ../gtk/gtkwindow.c:10052
#43 0x00007ffff7dee7a4 in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7fffffffcef0, instance=0x555555b7f5d0, return_value=0x0, closure=0x555555a009c0) at ../gobject/gclosure.c:897
#44 signal_emit_valist_unlocked (instance=instance@entry=0x555555b7f5d0, signal_id=signal_id@entry=109, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffcef0) at ../gobject/gsignal.c:3415
#45 0x00007ffff7dee8b1 in g_signal_emit_valist (instance=0x555555b7f5d0, signal_id=109, detail=0, var_args=var_args@entry=0x7fffffffcef0) at ../gobject/gsignal.c:3254
#46 0x00007ffff7dee973 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3574
#47 0x00007ffff7707b20 in gtk_container_idle_sizer (clock=0x555555b0b120, container=0x555555b7f5d0) at ../gtk/gtkcontainer.c:2066
#48 0x00007ffff7dee7a4 in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7fffffffd230, instance=0x555555b0b120, return_value=0x0, closure=0x5555564272a0) at ../gobject/gclosure.c:897
#49 signal_emit_valist_unlocked (instance=instance@entry=0x555555b0b120, signal_id=signal_id@entry=31, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd230) at ../gobject/gsignal.c:3415
#50 0x00007ffff7dee8b1 in g_signal_emit_valist (instance=0x555555b0b120, signal_id=31, detail=0, var_args=var_args@entry=0x7fffffffd230) at ../gobject/gsignal.c:3254
#51 0x00007ffff7dee973 in g_signal_emit (instance=instance@entry=0x555555b0b120, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574
#52 0x00007ffff7efcb44 in _gdk_frame_clock_emit_layout (frame_clock=0x555555b0b120) at ../gdk/gdkframeclock.c:651
#53 gdk_frame_clock_paint_idle (data=0x555555b0b120) at ../gdk/gdkframeclockidle.c:575
#54 0x00007ffff7ee8cbd in gdk_threads_dispatch (data=data@entry=0x555555f8b7f0) at ../gdk/gdk.c:769
--Type <RET> for more, q to quit, c to continue without paging--c
#55 0x00007ffff72153c9 in g_timeout_dispatch (source=0x555556342500, callback=0x7ffff7ee8c90 <gdk_threads_dispatch>, user_data=0x555555f8b7f0) at ../glib/gmain.c:4989
#56 0x00007ffff720f26c in g_main_dispatch (context=0x5555559ec6c0) at ../glib/gmain.c:3344
#57 g_main_context_dispatch_unlocked (context=0x5555559ec6c0) at ../glib/gmain.c:4152
#58 0x00007ffff72702a8 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x5555559ec6c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4217
#59 0x00007ffff72106e3 in g_main_context_iteration (context=0x5555559ec6c0, context@entry=0x0, may_block=may_block@entry=1) at ../glib/gmain.c:4282
#60 0x000055555583e90f in gui_mch_wait_for_chars (wtime=4000) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:6691
#61 gui_wait_for_chars_3 (wtime=wtime@entry=4000, interrupted=interrupted@entry=0x7fffffffd5fc, ignore_input=ignore_input@entry=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2957
#62 0x00005555557d78d8 in ui_wait_for_chars_or_timer (wtime=4000, wait_func=0x55555583e830 <gui_wait_for_chars_3>, interrupted=0x7fffffffd5fc, ignore_input=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/ui.c:488
#63 0x00005555557d82fd in inchar_loop (buf=0x555555982e5a <typebuf_init.lto_priv+90> "", maxlen=58, wtime=-1, tb_change_cnt=301, wait_func=0x55555583ea90 <gui_wait_for_chars_or_timer>, resize_func=<optimized out>)
at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/ui.c:384
#64 0x0000555555841e49 in gui_wait_for_chars_buf (buf=0x555555982e5a <typebuf_init.lto_priv+90> "", maxlen=58, wtime=-1, tb_change_cnt=301) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:3023
#65 0x00005555557d8ab5 in gui_inchar (tb_change_cnt=<optimized out>, wtime=-1, maxlen=58, buf=0x555555982e5a <typebuf_init.lto_priv+90> "") at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:3056
#66 ui_inchar (buf=0x555555982e5a <typebuf_init.lto_priv+90> "", maxlen=58, wtime=-1, tb_change_cnt=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/ui.c:226
#67 0x0000555555663778 in inchar (buf=0x555555982e5a <typebuf_init.lto_priv+90> "", maxlen=174, wait_time=-1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:3808
#68 0x0000555555664949 in vgetorpeek (advance=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:3593
#69 0x000055555565ffc4 in vgetc () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:1784
#70 0x00005555556c485e in safe_vgetc () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:2035
#71 normal_cmd (oap=0x7fffffffdba0, toplevel=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/normal.c:761
#72 0x000055555589157b in main_loop (cmdwin=cmdwin@entry=0, noexmode=noexmode@entry=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/main.c:1562
#73 0x000055555557e0c0 in vim_main2 () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/main.c:895
#74 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/main.c:441
Where there is the gdk_frame_clock_paint_idle function which by its description seems to be responsible for painting the window. It certainly is called every time switching from terminal to GVim. However, the same function is not called when the UI si frozen (but it is still called when trying e.g. the menu).
The question why it is not called. It seems the answer could be in some of the frames bellow the #53
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
The first frame that is from actual Vim code would be #60 0x000055555583e90f in gui_mch_wait_for_chars (wtime=4000) . I expect it would be interesting to see if a breakpoint there is reached in the frozen state. Maybe it can tell you if the problem is in GTK or in Vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
Yes, it is reachable. I am driving parallel discussion here:
https://discourse.gnome.org/t/gvim-ui-freezes/19448/9
My next target is focus_in_event from this call stack:
#0 maybe_start_idle (clock_idle=0x555556176230, caused_by_thaw=0) at ../gdk/gdkframeclockidle.c:298
#1 0x00007ffff7f0488c in impl_window_add_update_area (region=0x555556345b40, impl_window=0x555555aafa90) at ../gdk/gdkwindow.c:4357
#2 gdk_window_invalidate_maybe_recurse_full (window=0x555555aafa90, region=0x555556345910, child_func=<optimized out>, user_data=0x0) at ../gdk/gdkwindow.c:4486
#3 0x00007ffff79476a6 in gtk_widget_queue_draw_area (widget=0x555555fa8130, x=2, y=933, width=<optimized out>, height=19) at ../gtk/gtkwidget.c:5684
#4 0x00005555558488dd in gui_gtk2_draw_string_ext (force_pango=<optimized out>, flags=<optimized out>, len=<optimized out>, s=0x55555632b910 " ", col=1, row=49) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:6298
#5 gui_gtk2_draw_string (flags=<optimized out>, len=<optimized out>, s=<optimized out>, col=1, row=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:6034
#6 gui_outstr_nowrap (s=<optimized out>, s@entry=0x55555632b910 " ", len=<optimized out>, len@entry=1, flags=flags@entry=16, fg=fg@entry=0, bg=bg@entry=0, back=back@entry=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2518
#7 0x000055555584a614 in gui_screenstr (fg=0, bg=0, back=<optimized out>, flags=<optimized out>, len=<optimized out>, off=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2234
#8 gui_redraw_block (row1=<optimized out>, col1=<optimized out>, row2=<optimized out>, col2=<optimized out>, flags=flags@entry=16) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2847
#9 0x000055555584a87d in gui_redraw_block (flags=16, col2=<optimized out>, row2=<optimized out>, col1=<optimized out>, row1=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2753
#10 gui_undraw_cursor () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2697
#11 0x000055555583d16d in gui_undraw_cursor () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:1176
#12 gui_update_cursor (force=<optimized out>, clear_selection=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:1179
#13 0x00005555557ad7b2 in out_flush_cursor (clear_selection=0, force=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/term.c:2780
#14 out_flush_cursor (force=1, clear_selection=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/term.c:2770
#15 0x0000555555841103 in gui_focus_change (in_focus=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:4720
#16 focus_in_event (widget=widget@entry=0x555555f833c0, event=<optimized out>, data=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:1065
#17 0x00007ffff768d5f4 in _gtk_marshal_BOOLEAN__BOXED (closure=0x555555fa8b40, return_value=0x7fffffffce60, param_values=0x7fffffffcef0, marshal_data=<optimized out>, invocation_hint=<optimized out>, n_param_values=<optimized out>)
at gtk/gtkmarshalers.c:84
#18 0x00007ffff7dce4da in g_closure_invoke (closure=0x555555fa8b40, return_value=0x7fffffffce60, n_param_values=2, param_values=0x7fffffffcef0, invocation_hint=0x7fffffffce40) at ../gobject/gclosure.c:834
#19 0x00007ffff7dfd903 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffcff0, detail=detail@entry=0, instance=instance@entry=0x555555f833c0, emission_return=emission_return@entry=0x7fffffffd070,
instance_and_params=instance_and_params@entry=0x7fffffffcef0) at ../gobject/gsignal.c:3879
#20 0x00007ffff7dedeb9 in signal_emit_valist_unlocked (instance=instance@entry=0x555555f833c0, signal_id=signal_id@entry=73, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd160) at ../gobject/gsignal.c:3524
#21 0x00007ffff7dee8b1 in g_signal_emit_valist (instance=0x555555f833c0, signal_id=73, detail=0, var_args=var_args@entry=0x7fffffffd160) at ../gobject/gsignal.c:3254
#22 0x00007ffff7dee973 in g_signal_emit (instance=instance@entry=0x555555f833c0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574
#23 0x00007ffff795d314 in gtk_widget_event_internal.part.0.lto_priv.0 (widget=0x555555f833c0, event=0x555555b714f0) at ../gtk/gtkwidget.c:7812
#24 0x00007ffff77f3f9c in gtk_main_do_event (event=<optimized out>) at ../gtk/gtkmain.c:1861
#25 gtk_main_do_event (event=<optimized out>) at ../gtk/gtkmain.c:1691
#26 0x00007ffff7eef457 in _gdk_event_emit (event=0x555555b714f0) at ../gdk/gdkevents.c:73
#27 _gdk_event_emit (event=0x555555b714f0) at ../gdk/gdkevents.c:67
#28 0x00007ffff7f4934e in gdk_event_source_dispatch.lto_priv () at ../gdk/x11/gdkeventsource.c:354
#29 0x00007ffff720f26c in g_main_dispatch (context=0x5555559ec760) at ../glib/gmain.c:3344
#30 g_main_context_dispatch_unlocked (context=0x5555559ec760) at ../glib/gmain.c:4152
#31 0x00007ffff72702a8 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x5555559ec760, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4217
#32 0x00007ffff72106e3 in g_main_context_iteration (context=0x5555559ec760, context@entry=0x0, may_block=may_block@entry=1) at ../glib/gmain.c:4282
#33 0x000055555583e90f in gui_mch_wait_for_chars (wtime=-481852) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui_gtk_x11.c:6691
#34 gui_wait_for_chars_3 (wtime=wtime@entry=-481852, interrupted=interrupted@entry=0x7fffffffd5fc, ignore_input=ignore_input@entry=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:2957
#35 0x00005555557d78d8 in ui_wait_for_chars_or_timer (wtime=-481852, wait_func=0x55555583e830 <gui_wait_for_chars_3>, interrupted=0x7fffffffd5fc, ignore_input=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/ui.c:488
#36 0x00005555557d82fd in inchar_loop (buf=0x555555982e45 <typebuf_init.lto_priv+69> "", maxlen=65, wtime=-1, tb_change_cnt=19, wait_func=0x55555583ea90 <gui_wait_for_chars_or_timer>, resize_func=<optimized out>)
at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/ui.c:384
#37 0x0000555555841e49 in gui_wait_for_chars_buf (buf=0x555555982e45 <typebuf_init.lto_priv+69> "", maxlen=65, wtime=-1, tb_change_cnt=19) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:3023
#38 0x00005555557d8ab5 in gui_inchar (tb_change_cnt=<optimized out>, wtime=-1, maxlen=65, buf=0x555555982e45 <typebuf_init.lto_priv+69> "") at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/gui.c:3056
#39 ui_inchar (buf=0x555555982e45 <typebuf_init.lto_priv+69> "", maxlen=65, wtime=-1, tb_change_cnt=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/ui.c:226
#40 0x0000555555663778 in inchar (buf=0x555555982e45 <typebuf_init.lto_priv+69> "", maxlen=195, wait_time=-1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:3808
#41 0x0000555555664949 in vgetorpeek (advance=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:3593
#42 0x000055555565ffc4 in vgetc () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:1784
#43 0x00005555556c485e in safe_vgetc () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/getchar.c:2035
#44 normal_cmd (oap=0x7fffffffdba0, toplevel=1) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/normal.c:761
#45 0x000055555589157b in main_loop (cmdwin=cmdwin@entry=0, noexmode=noexmode@entry=0) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/main.c:1562
#46 0x000055555557e0c0 in vim_main2 () at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/main.c:895
#47 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/vim-9.1.083-1.fc40.x86_64/src/main.c:441
But it is not the fastest progress, doing my regular work, which is interrupted by dives into GVim, because this happens just randomly. But I am dedicated to crack it 💪 (unless warnings from Wayland version are mitigated)
—
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
It seems that gui_focus_change even is reachable. At least something. But what next?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
I've seen this discussion going by, not in detail.
I've noticed that there is no talk of a log file, see :help ch_log and related and there's --log <file>. This can be handy for seeing what was going on before the problem occurs.
—
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 noticed that there is no talk of a log file, see
:help ch_logand related and there's--log <file>. This can be handy for seeing what was going on before the problem occurs.
This is good idea. I have tried to run GVim with the --log and here is the log file (I hope that nobody is going to reconstruct my super secret work out of it 🙈). I think that the instance was frozen already at ~160 seconds mark. The git --no-pager command is executed by gitgutter plugin every time I switch back to GVim.
Not sure what I am supposed to see there though. However, it comes interesting that the 174.196479713 on 5: Freeing job comes quite late after git command execution (comparing to the previous instances).
—
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
Also trying GTK inspector if I can spot some difference somewhere. In the main window, there is in "Tick callback". Initially, there is no:
Snimek.obrazovky.z.2024-02-20.12-45-19.png (view on web)
but there is some when the window is frozen:
Snimek.obrazovky.z.2024-02-20.14-10-54.png (view on web)
and mnemonics-visible property is TRUE originally:
Snimek.obrazovky.z.2024-02-20.12-46-23.png (view on web)
but FALSE when the GUI is frozen:
Snimek.obrazovky.z.2024-02-20.14-10-16.png (view on web)
I can't say I am smart from the documentation:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
So here is some analysis from Gnome folks:
Ok, the
GdkFrameClockis frozen, which explains why nothing happens anymoreThawing / freezing happens only in two places:
Somehow the calls are not balanced. As this happens only with GNOME (which AFAIK is the only WM implementing
_NET_WM_FRAME_DRAWN), most probably it’s the second: the X11 backend.Yeah, it would be great to have a
reasonfield to track why a frame clock is frozen
Perhaps the event filter installed by gvim is filtering
_NET_WM_FRAME_DRAWNevents? vim/src/gui_gtk_x11.c at fa37835b8c0ed0f83952978fca4c332335ca7c46 · vim/vim · GitHub
—
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
Based on that, I was able to experimentally unfreeze the window in gdb like this:
(gdb) set $gdk_win = (GdkWindow*)gtk_widget_get_window (gui.mainwin)
(gdb) set $frameclock = gdk_window_get_frame_clock ($gdk_win)
(gdb) p *((GdkFrameClockIdle*)$frameclock)->priv
$98 = {frame_time = 538586369936, smoothed_frame_time_base = 538586373751, smoothed_frame_time_period = 16681, smoothed_frame_time_reported = 592837623069, smoothed_frame_time_phase = 0, min_next_frame_time = 0,
smooth_phase_state = SMOOTH_PHASE_STATE_AWAIT_FIRST, sleep_serial = 2204, flush_idle_id = 0, paint_idle_id = 0, freeze_count = 1, updating_count = 1,
requested = (GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS | GDK_FRAME_CLOCK_PHASE_LAYOUT | GDK_FRAME_CLOCK_PHASE_PAINT), phase = GDK_FRAME_CLOCK_PHASE_NONE, in_paint_idle = 0, paint_is_thaw = 0}
(gdb) call _gdk_frame_clock_thaw ($frameclock)
(gdb) c
Continuing.
And later confirm the freeze_count = 0 (which is hopefully the right value to look at):
^C
Thread 1 "gvim" received signal SIGINT, Interrupt.
0x00007ffff6d3b73d in __GI___poll (fds=0x555556b2f1a0, nfds=5, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29 return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) p *((GdkFrameClockIdle*)$frameclock)->priv
$99 = {frame_time = 594464622115, smoothed_frame_time_base = 594464622115, smoothed_frame_time_period = 16667, smoothed_frame_time_reported = 594464622115, smoothed_frame_time_phase = 0, min_next_frame_time = 594464638782,
smooth_phase_state = SMOOTH_PHASE_STATE_VALID, sleep_serial = 8444, flush_idle_id = 0, paint_idle_id = 0, freeze_count = 0, updating_count = 0, requested = GDK_FRAME_CLOCK_PHASE_NONE, phase = GDK_FRAME_CLOCK_PHASE_NONE,
in_paint_idle = 0, paint_is_thaw = 0}
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
I think there might be more possibly related issue. For example, I have never really noticed that, but since I am poking around the code, the cursor in the window should be blinking. However it does not blink. It blinks just like 3 times when the window get focus, but then it stops.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
Of course the more I try to catch the issue, the more GVim resists. So just let me describe my latest attempt.
$ gdb --args gvim newpackage.spec -f
GNU gdb (Fedora Linux) 14.1-8.fc40
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gvim...
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from /home/vondruch/.cache/debuginfod_client/abf54ebdaef584801d8648a0e643c883d71d6b1d/debuginfo...
(gdb) r
Starting program: /usr/bin/gvim newpackage.spec -f
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff5a006c0 (LWP 1120555)]
[New Thread 0x7fffefe006c0 (LWP 1120556)]
[New Thread 0x7ffff50006c0 (LWP 1120557)]
[New Thread 0x7fffef4006c0 (LWP 1120558)]
[Thread 0x7fffef4006c0 (LWP 1120558) exited]
[New Thread 0x7fffef4006c0 (LWP 1120559)]
[New Thread 0x7fffeea006c0 (LWP 1120560)]
[Thread 0x7fffef4006c0 (LWP 1120559) exited]
[Thread 0x7fffeea006c0 (LWP 1120560) exited]
[New Thread 0x7fffeea006c0 (LWP 1120561)]
[New Thread 0x7fffef4006c0 (LWP 1120562)]
[Thread 0x7fffeea006c0 (LWP 1120561) exited]
[New Thread 0x7fffeea006c0 (LWP 1120563)]
[New Thread 0x7fffee0006c0 (LWP 1120564)]
[Thread 0x7fffeea006c0 (LWP 1120563) exited]
[Thread 0x7fffef4006c0 (LWP 1120562) exited]
[Thread 0x7fffee0006c0 (LWP 1120564) exited]
[New Thread 0x7fffee0006c0 (LWP 1120565)]
[New Thread 0x7fffef4006c0 (LWP 1120566)]
[Thread 0x7fffee0006c0 (LWP 1120565) exited]
[Thread 0x7fffef4006c0 (LWP 1120566) exited]
[New Thread 0x7fffef4006c0 (LWP 1120567)]
[New Thread 0x7fffee0006c0 (LWP 1120568)]
[New Thread 0x7ffff50a6d40 (LWP 1120572)]
[Detaching after fork from child process 1120573]
[Detaching after fork from child process 1120574]
[Detaching after fork from child process 1120576]
[Detaching after fork from child process 1120578]
[Thread 0x7fffef4006c0 (LWP 1120567) exited]
^C
Thread 1 "gvim" received signal SIGINT, Interrupt.
0x00007ffff6d3b73d in __GI___poll (fds=0x5555560cf500, nfds=4, timeout=3444) at ../sysdeps/unix/sysv/linux/poll.c:29
29 return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) set $gdk_win = (GdkWindow*)gtk_widget_get_window (gui.mainwin)
(gdb) set $frameclock = gdk_window_get_frame_clock ($gdk_win)
[Thread 0x7fffee0006c0 (LWP 1120568) exited]
(gdb) p *((GdkFrameClockIdle*)$frameclock)->priv
$1 = {frame_time = 1238526680261, smoothed_frame_time_base = 1238526680261, smoothed_frame_time_period = 16667, smoothed_frame_time_reported = 1238526680261, smoothed_frame_time_phase = 0, min_next_frame_time = 0,
smooth_phase_state = SMOOTH_PHASE_STATE_VALID, sleep_serial = 522, flush_idle_id = 0, paint_idle_id = 0, freeze_count = 0, updating_count = 0, requested = GDK_FRAME_CLOCK_PHASE_NONE, phase = GDK_FRAME_CLOCK_PHASE_NONE,
in_paint_idle = 0, paint_is_thaw = 1}
(gdb) watch ((GdkFrameClockIdle*)$frameclock)->priv->freeze_count
Hardware watchpoint 1: ((GdkFrameClockIdle*)$frameclock)->priv->freeze_count
(gdb) set height 0
(gdb) set logging on
Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled on'.
Copying output to gdb.txt.
Copying debug output to gdb.txt.
(gdb) set logging redirect on
warning: Currently logging to gdb.txt. Turn the logging off and on to make the new setting effective.
(gdb) command
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>bt
>cont
>end
(gdb) c
Continuing.
So this session starts GVim without forking, I break the run by Ctrl+C and setup some convenience vars, where the ((GdkFrameClockIdle*)$frameclock)->priv->freeze_count is the value of interest. Therefore I set a watch on it, which triggers the command printing the backtrace. When the GUI gets frozen, it stays at 1 and there should be the related backtraces stored in gdb.txt file.
But of course when I am not trying to catch the backtraces, it freezes sometimes even right after I switch to GDB for the first time. But when I try to get them, it seems to be stable. But maybe somebody will be more lucky. And of course I'll keep trying and rung my GVim with DGB attached all the time.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mladen Mijatov
I think there might be more possibly related issue. For example, I have never really noticed that, but since I am poking around the code, the cursor in the window should be blinking. However it does not blink. It blinks just like 3 times when the window get focus, but then it stops.
This is a GTK+ thing. If you open Gnome Terminal and let it sit idle, cursor will stop blinking after short period of time. Not really 3 blinks, but 10 or 20 seconds.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
I think there might be more possibly related issue. For example, I have never really noticed that, but since I am poking around the code, the cursor in the window should be blinking. However it does not blink. It blinks just like 3 times when the window get focus, but then it stops.
This is a GTK+ thing. If you open Gnome Terminal and let it sit idle, cursor will stop blinking after short period of time. Not really 3 blinks, but 10 or 20 seconds. Not only terminal, any GTK+ entry.
Interesting. I have never noticed this. Vim behaves the same as terminal. Gvim flashes like 2-3 times and stops. Everything like in less then second.
Chm.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
Now I am poking Haiku GUI. Interestingly, there is spawned separate thread to handle the BApplication message loop. GTK folks says that GVim is problematic due to GVim not running the main loop. Wouldn't it be better to do for GTK something similar the Haiku does?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
BTW from time to time, I see also other GUI artifacts. E.g. when I maximize window, there stays the normalized size border visible over the UI.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
--
Sent from my Android device with K-9 . Please excuse my brevity.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Runar Ingebrigtsen
@voxik Just going to say I really appreciate your effort evident here. This issue is a daily chore for me.
Vim GUI hangs, but seems to behave normal, just invisible. No issues on the terminal.
Version of Vim
vim 2:9.0.0749-0york0~22.04 (PPA package)
Environment
Ubuntu 22.04.4 LTS
GNOME
Guake Terminal
Wayland session
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.