GVim UI freezes

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
Wayland session
Logs and stack traces
No response

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 &

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

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

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

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.

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.

I'll give a try to vim --clean

Which makes no difference :(

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?

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

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

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

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

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.

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.

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 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...).

but making Vim maximized could well be a workaround.

The exact opposite actually seems to be the workaround.

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.

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.

i got the same error on fedora 38

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)

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?

vim-version.txt

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.

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

simply switch to xorg :) joke

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.

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

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.

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)

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

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

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.?
Also during one of my attempts it actually worked correctly, but the next attempt failed again.

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();

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.

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.

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 https://github.com/vim/vim/issues/12671#issuecomment-1917935092 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...

According to git blame, that particular code comes from 071d4279d6ab81b7187b48f3a0fc61e 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...)

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

and what is :set termencoding?

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=

hm, okay. Not sure then why gvim wants to convert the s buffer 🤷

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...

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?

Sure, will do. I'll also try to see if I can bisect it, I'm curious...

Bisection points to this:
f6d39c31d2177549a986d170e192d8351bd571e2 is the first bad commit
commit f6d39c31d2177549a986d170e192d8351bd571e2
Author: Bram Moolenaar<EMAIL_ADDRESS>Date:   Tue Aug 16 17:50:38 2022 +0100

    patch 9.0.0220: invalid memory access with for loop over NULL string

    Problem:    Invalid memory access with for loop over NULL string.
    Solution:   Make sure mb_ptr2len() consistently returns zero for NUL.

 src/globals.h                   |  3 ++-
 src/mbyte.c                     | 21 +++++++++++++--------
 src/testdir/test_eval_stuff.vim | 12 ++++++++++++
 src/version.c                   |  2 ++
 4 files changed, 29 insertions(+), 9 deletions(-)

That's not really what I wanted to find, but it does make sense: this is the first commit which causes the infinite loop. And the modified function latin_ptr2len() is indeed involved in this loop: it returns 0 and makes the loop infinite.
I have the sneaky suspicion that when this patch was made, it was also because the uninitialized ScreenLines made some trouble. Maybe some old mailing list message contains more information than this commit message...

ah, that makes sense. This is a fix for CVE-2022-2849

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.

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. 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.

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?

@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.

@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() in gui_gtk_x11.c might 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

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.

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.

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 🤷

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
[^1]: 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

Just stumbled upon #12070, where the same symptoms are described

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.

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:
https://github.com/vim/vim/blob/79230f027a25ff12eb7c7b64e1c063297876aae2/src/gui_gtk_x11.c#L4080-L4083
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

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.

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)

It seems that gui_focus_change even is reachable. At least something. But what next?

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.

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.

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<PHONE_NUMBER>13 on 5: Freeing job comes quite late after git command execution (comparing to the previous instances).

Also trying GTK inspector if I can spot some difference somewhere. In the main window, there is in "Tick callback". Initially, there is no:

but there is some when the window is frozen:

and mnemonics-visible property is TRUE originally:

but FALSE when the GUI is frozen:

I can't say I am smart from the documentation:

So here is some analysis from Gnome folks:

Ok, the GdkFrameClock is frozen, which explains why nothing happens anymore
Thawing / freezing happens only in two places:

gdkwindow.c: freeze  and thaw
the X11 backend: freeze  and thaw1 , thaw2

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 reason field to track why a frame clock is frozen

Perhaps the event filter installed by gvim is filtering _NET_WM_FRAME_DRAWN events? vim/src/gui_gtk_x11.c at fa37835b8c0ed0f83952978fca4c332335ca7c46 · vim/vim · GitHub

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 =<PHONE_NUMBER>36, smoothed_frame_time_base =<PHONE_NUMBER>51, smoothed_frame_time_period = 16681, smoothed_frame_time_reported =<PHONE_NUMBER>69, 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 =<PHONE_NUMBER>15, smoothed_frame_time_base =<PHONE_NUMBER>15, smoothed_frame_time_period = 16667, smoothed_frame_time_reported =<PHONE_NUMBER>15, smoothed_frame_time_phase = 0, min_next_frame_time =<PHONE_NUMBER>82,
  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}

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.

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 =<PHONE_NUMBER>261, smoothed_frame_time_base =<PHONE_NUMBER>261, smoothed_frame_time_period = 16667, smoothed_frame_time_reported =<PHONE_NUMBER>261, 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.

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 might be 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.

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.

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?

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.

Interesting that you look at that. I wrote the BeOS gui back in the day.
Sent from my Android device with K-9 . Please excuse my brevity.

@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

Hi, I hope I am not repeating something already known here. I have a way to trigger the lock every time.

Open a file with gvim file.txt. Switch to edit mode, change things.
leave it in input mode
Switch desktop
Go back

The interface is frozen, but you can, for example, issue "ESC ZZ" and it works.
 System:
  Host: ramoth Kernel: 6.6.47-1-MANJARO arch: x86_64 bits: 64
  Desktop: GNOME v: 46.4 Distro: Manjaro Linux

gvim --version
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Aug 22 2024 20:12:11)
Included patches: 1-689
Compiled by Arch Linux

The interface is frozen, but you can, for example, issue "ESC ZZ" and it works.

Oh, nice. Finally some more details. Good to know there is a way to recover.

leave it in insert mode

Now I see that you have tried to highlight this and your hack is stopping the insert mode. Nice findings.
I still wonder, are you using multiple monitors or only single one?

The interface is frozen, but you can, for example, issue "ESC ZZ" and it works.

Oh, nice. Finally some more details. Good to know there is a way to recover.

Ok, not a way to recover, just to close the window 🤦


POST to api/operation fails: User does not have adequate access rights

On the most recent firmware - this command:
curl -k --header "Authorization: Bearer SK_MY_BEARER_TOKEN==" -X POST -d '{"mode":"self_consumption","backup_reserve_percent":24.6}' https://THE_IP/api/operation
Seems to fail with this error:
{"code":403,"error":"Unable to POST to resource","message":"User does not have adequate access rights"}%

It worked a while ago (as I was using this in http://github.com/terafin/mqtt-tesla-bridge), but it seems quite dead now.
I've tried various forms of installer logins (resetting password on GW, etc). Am I missing something, has anyone had any success with POSTs to change mode?

See discussion at #34
Control needs to be via the cloud API - which is itself problematic at the moment.

@BJReplay thank you! Yikes... that's less than stellar. I'll follow along there. Cheers!

@terafin make sure you follow the discussions at https://github.com/timdorr/tesla-api/discussions/ and the instructions at https://tesla-api.timdorr.com/ but note that Tesla seem to be making it harder and harder to use the cloud API.
My controller is using Tim Hollander's auth library https://github.com/tomhollander/TeslaAuth and is currently able to renew a token, but new login attempts fail.

Note this seems to work, when I nabbed the installer cookie from logging in as an installer (and toggling the gateway)...
curl -k --cookie "AuthCookie=XXXXXX==; UserRecord=XXXXXXXXYYYY=="  -X POST -d '{"mode":"self_consumption","real_mode":"self_consumption","backup_reserve_percent":24.6}' https://MY_IP/api/operation

Will watch for how long this auth cookie lasts for...

Looks like around 10 hours or so

The following works for me (example using session cookie):
curl -k -O -c cookies.txt -X POST https://IP-Powerwall/api/login/Basic -H "Content-Type: application/json"
-d "{\"username\": \"customer\",\"email\": \"your.login@mail.address\",\"password\": \"yourPassword\"}"

curl -k -O -b cookies.txt https://IP-Powerwall/api/meters/aggregates

Note: I had to reset the Powerwall and enter the new customer password to get it working, but YMMV.

Yup, works great for that request, but doesn’t seem to work for a POST to the operation endpoint

Yup, works great for that request, but doesn’t seem to work for a POST to the operation endpoint

yeah, customer login allows you to stop and start, but not change modes.  Still need installer mode (which still needs a physical switch toggle) for that - so you're really forced to use the telsa (cloud) API that the phone apps use.


Update AboutUs.md

Coverage remained the same at 92.058% when pulling 044d95f44efab4ed81275a6b51411f974b1a160e on update-docs into 3298a6f09474680dfe81b77893e50fa09d20aca3 on development.


Devise::Models::Authenticatable::BLACKLIST_FOR_SERIALIZATION is deprecated

When posting issues, please include the following information to speed up the troubleshooting process:

Version: 1.1.5 (Reproduced with github master as well)
Request and response headers: N/A
Rails Stacktrace: DEPRECATION WARNING: Devise::Models::Authenticatable::BLACKLIST_FOR_SERIALIZATION is deprecated! Use  Devise::Models::Authenticatable::UNSAFE_ATTRIBUTES_FOR_SERIALIZATION instead. (called from <top (required)> at ...)

Environmental Info: N/A - unrelated to app.

See the change in the changelog: https://github.com/heartcombo/devise/blob/master/CHANGELOG.md
The issue is in https://github.com/lynndylanhurley/devise_token_auth/blob/master/lib/devise_token_auth/blacklist.rb.

PR #1473 is on this, but seems to require a devise update.

This was merged to master

temporary solution: gem 'devise_token_auth', github: 'lynndylanhurley/devise_token_auth', branch: 'master'

isn't fixed yet?

Release for this?


Fix sloppy focus issues around desktop windows (file managers, etc)

This combines two separate commits that fix some issues with JWM's sloppy focus.
The user probably considers background widows, like those provided by file managers, to be something other than a regular window, and might consider sloppy focus to be broken by them (see joewing/jwm#613). In point of fact, these windows should probably not receive sloppy focus; however they can still be usefully focussed and interacted with.
Therefore, require clicks before interaction even in sloppy focus mode.
They also may not appreciate a giant rectangle in the pager behind all the other ones. You can't usefully move one of these background filer windows, and it probably shouldn't hide the pager's desktop number either if the current desktop happens to be empty.

For some reason, I wasn't able to test with np->state.windowType != WINDOW_TYPE_DESKTOP (the results felt like click-to-focus instead). Since that's 0 in the enum, is it being set correctly for regular windows? :thinking:
If you prefer, I can reimplement this patch and investigate.

Looks like windowType wasn't being properly initialized during construction. I'm not sure what the full ramifications of that will be, but a default to WINDOW_TYPE_NORMAL seems safe.
@joewing Let me know if you want this rebasing before you accept it, since it changes the same lines twice.

@joewing Does the exception this branch introduces for desktop windows while in sloppy focus modes need documenting? I don't think the pager stuff does, necessarily.

I think the logic and behaviour is right now.
@joewing
Let me know if you'd prefer me to rebase it into a couple of commits, and/or if anything needs to be changed stylistically.

This looks reasonable to me. Thanks!


[native filter] when user undo delete of a native filter, the options under column is gone

For value filter, when user undo delete of a native filter, the options under column is gone, however if user go to another filter and come back, the options will appear again
How to reproduce the bug

Create a value native filter
Click on delete and then undo delete
open dropdown menu for column
See error

Expected results
When user undo delete, the options in column dropdown list will not disappear
Actual results
When user undo delete, the options in column dropdown list will disappear
Screenshots
https://user-images.githubusercontent.com/81597121/135208961-d9acdead-f57a-4ae7-9283-82e613bf3486.mov
Environment
(please complete the following information):

browser type and version:
superset version:  superset master
python version: python --version
node.js version: node -v
any feature flags active:

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

Resolved by #17951


Fluent::BufferChunk should support msgpack_map

fluent-plugin-mongo has follwing code:
records = []
chunk.msgpack_each { |record|
  record[@time_key] = Time.at(record[@time_key]) if @include_time_key
  records << record
}

I think this pattern is often-used in some OutputPlugins.
BufferChunk#msgpack_map gets rid of such pattern and
we have the chance to improve speed than msgpack_each.

Thank you.
First, I agree with you that "msgpack_map" is useful in some cases. It will widen design choice. But in this case, you can do the map operation in the "format" method.
Generally, "write(chunk)" method shouldn't process records. Instead, just do writing. There are two reasons:

"write(chunk)" method will be called multiple times when it is retried.
"format" method can raise an error to input plugin (and client applications) if the record is invalid. But "write(chunk)" method can't.
(There is also advantage. Since "write(chunk)" method is called in the different thread of input plugin, processing records in "write(chunk)" method will reduce latency of Engine.emit)

Second, it's difficult to improve performance. One way to improve performance of "#map" is creating a map with specified size and reduce overhead of memory allocation. But in this case, no one can know size of map before deserializing (note that msgpack_each does streaming deserialization).
So, how do you think? msgpack_map is still useful?

you can do the map operation in the "format" method.

Right? In Mongo, time field needs Time object but MessagePack can't serialize such objects.

There are two reasons:

Thanks for the explanation. Hmm, I understand the different roles of "write" and "format".

Second

I see.

msgpack_map is still useful?

Yes for the code clarification. No for other reasons.
This issue is not critical.
I leave a decision up to you :)


mkdocs doesn't look in the root of the repo

When you choose Mkdocs as your Documentation Type, we will first look for a mkdocs.yml file in the root of your repository. If we don’t find one, we will generate one for you.

The above is not true. I had a project with mkdocs.yml in the root (along with relevant markdown files), and the build failed-- I was getting the same error referenced in #4231.

A link to your rtd project and build would be helpful here, anyway, I think your issue was because of the docs_dir was at the same level of the mkdocs.yml file instead of a child directory, and btw, I think you mention that moving all inside docs solved the issue. It does, but we are not longer reading your mkdocs.yml file, but generating one for you in the root of your project.

Ah, you are correct! Just tested this here: https://github.com/AumitLeon/module_starter_cli/pull/35


Finished Project Page - Required finished by staff name in project details view by Suresh sir

Describe the bug

This is upcoming feature / module, so developing new feature different from module should not be entertained


[Question] v2.2.0+ on Maven Central

Hi Guys,
The newest release on GitHub is 2.5.0, but the latest version on Maven Central is 2.2.0:
https://repo.maven.apache.org/maven2/com/phrase/phrase-java/
Don't you have any plans or schedules for when the latest version will be available on Maven Central?
Regards,

Hi @IShmelov our maven central access was broken for a while, but it should be fixed now, soon we plan to release a new version of all clients and Java will hopefully be there. I'll leave this issue open until then.

hey @IShmelov version 2.6 is pushed to Maven Central https://central.sonatype.com/artifact/com.phrase/phrase-java/versions


GPG keyserver receive failed: No data

Etcher version: none yet
Operating system and architecture: Debian 9.2 i386
Image flashed: none yet
Do you see any meaningful error information in the DevTools? nope...??

sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 379CE192D401AB61
Executing: /tmp/apt-key-gpghome.4JhYetPTcO/gpg.1.sh --keyserver hkp://pgp.mit.edu:80 --recv-keys 379CE192D401AB61
gpg: keyserver receive failed: No data
W: GPG error: https://dl.bintray.com/resin-io/debian stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 379CE192D401AB61
E: The repository 'https://dl.bintray.com/resin-io/debian stable Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
I've been having some unrelated driver issues on my netbook so I've had to re-install Debian a few times, when I tried to add the etcher repo this is what I ran into above ^
Any ideas how I can get this thing working?

Oh that's funny, its working now. not sure why it kept failing. Sorry! Can't understand why it would just suddenly start to work again...  ah well!

Might just have been a temporary failure on the pgp.mit.edu server?

Honestly I am not sure. I kept trying it & it kept failing, I came back to it a little later, just after making this thread, and it suddenly started working.. Weird.

Mine still fails on Debian 9 stretch 64 bit as below.
W: GPG error: https://dl.bintray.com/resin-io/debian stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 379CE192D401AB61
W: The repository 'https://dl.bintray.com/resin-io/debian stable Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Kindly assist.

I ran the command below and no errors appear after running the apt-get update command
sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 379CE192D401AB61


pipenv sync unexpected behavior when Pipfile missing

Pipfile:
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[packages]
aioredis = "*"

[dev-packages]
ipython = "*"

[requires]
python_version = "3.6"

Generate Pipefile.lock for the above, delete Pipfile, and then:
$ pipenv sync
...
$ cat Pipfile.lock
{
    "_meta": {
        "hash": {
            "sha256": "4e55147db217bb4120f6e68cb8cad7bc37011457441ce0eb9d97308315625834"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.python.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {},
    "develop": {}
}

Expected result
pipenv installs the packages in Pipfile.lock.
Actual result
pipenv installs no packages and replaces Pipfile.lock with a new file containing no packages.

I can send a PR to fix this quickly but I would like to go further into the missing features of pipenv sync, such as dry_run, dont_upgrade. It seems far from complete. Thanks

There are some bugs in here that should get sorted out, so that would be appreciated?

@techalchemy I think this should be reopened. When I put Pipfile.lock without the Pipfile in a Docker image and run pipenv sync in the directory with Pipfile.lock I'm getting: Error: Pipfile.lock is missing! You need to run $ pipenv lock first.. When I copy the Pipfile as well the problem disappears.

Just had the same issue as @butla. Took me a while to understand that the error message was incorrect. Pipfile was missing, Pipfile.lock was present, and I got
Error: Pipfile.lock is missing! You need to run $ pipenv lock first.

Sorry about that, error message seems to be pretty clearly wrong on this one!


[WIP] Standards Toolkit v2

Overview
This PR contains all updates for v2.0.0 of the Standards Toolkit.
Link to preview
Reason
As we're bumping the Toolkit to v2.0.0, this PR will contain all breaking changes that cannot be merged into v1.x.x.
Work carried out

[ ] SCSS Framework changes

[ ] Changed the Spacing API to be linear in scale
[x] Changed all references of Helper to Utility to be more consistent with the function of these classes
[ ] Increased the number of available helpers to include:

[ ] Borders
[ ] Breakpoints
[ ] Clearfix
[ ] Colours
[ ] Containers
[ ] Dividers
[ ] Display
[ ] Floats
[ ] Overflow
[ ] Vertical Align

Apparently you can't turn an open PR into a Draft. Thanks Github.


Update CJK search documentation

Summary
Congrats on Mattermost 8.0 🎉
Updated the documentation for CJK search to align with the current environment.

Hello @Sharuru,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.


Synchronous mutation and classic update/delete statement support

Mutation executes asynchronously in ClickHouse. And unlike other databases following SQL standard, it uses DDL instead of DML. As a result, this may break assumption in certain tools and generate overhead in downstream applications.
In order to follow standards, I hope we can:

introduce a new connection setting mutationAsync(same as mutations_sync in ClickHouse) defaults to 1, meaning synchronous mutation
take classic update/delete and transform them into ALTER TABLE... for mutation in ClickHouse
So if you give UPDATE tbl SET col1=1, col2=2 WHERE col3=3, it will be translated into ALTER TABLE tbl UPDATE col1=1, col2=2 WHERE col3=3.

2 is a bad idea. Mutations were made this way (with special syntax) intentionally - current ALTER UPDATE / DELETE is very expensive operations, which should be used with care, not too often.
Drivers should NOT introduce any magic to pretend that clickhouse has updates or deletes (hopefully they will be added in 2021).

2 is a bad idea. Mutations were made this way (with special syntax) intentionally - current ALTER UPDATE / DELETE is very expensive operations, which should be used with care, not too often.
Drivers should NOT introduce any magic to pretend that clickhouse has updates or deletes (hopefully they will be added in 2021).

2 is a bad idea. Mutations were made this way (with special syntax) intentionally - current ALTER UPDATE / DELETE are very expensive operations, which should be used with care, not too often.
Drivers should NOT introduce any magic to pretend that clickhouse has updates or deletes (hopefully they will be added in 2021).

Thanks @filimonov. Got same feedback from @den-crane :) Any concern for synchronous mutation by default?

2 is a bad idea. Mutations were made this way (with special syntax) intentionally - current ALTER UPDATE / DELETE are very expensive operations, which should be used with care, not too often.
Drivers should NOT introduce any magic to pretend that clickhouse has updates or deletes (hopefully they will be added in 2021).

Thanks @filimonov. Got same feedback from @den-crane :) Any concern for synchronous mutation by default?

Any concern for synchronous mutation by default?

My preference is to map clickhouse settings as is (not inventing them) and having the same defaults as clickhouse.
So if ClickHouse has mutations_sync driver may have mutationsSync, and if the user need to run them syncronously he can just set it to 1 (or 2 if he also care about replicas) during driver initialization.

Any concern for synchronous mutation by default?

My preference is to map clickhouse settings as is (not inventing them) and having the same defaults as clickhouse.
So if ClickHouse has mutations_sync driver may have mutationsSync, and if the user need to run them syncronously he can just set it to 1 (or 2 if he also care about replicas) during driver initialization.

My preference is to map clickhouse settings as is (not inverting them) and having the same defaults as clickhouse.

OK, the "ClickHouse way".

My preference is to map clickhouse settings as is (not inverting them) and having the same defaults as clickhouse.

OK, the "ClickHouse way".

Before light-weight mutation in place, since multi-statement SQL is now supported, we can run SQL like below in one run - session will be enabled automatically if the SQL contains multiple statements:
set mutations_sync = 1;

ALTER TABLE tbl UPDATE col1=1, col2=2 WHERE col3=3;


Fix invalid mono log file name on Windows

Fixes #28388 (The - to _ is not really needed, I just think it's more readable)

Cherry-picked for 3.1.1.


Measure duration

DurationTimer class is intended to capture device performance such as the commissioning sub-processes. DurationTimer is meant to be device agnostic and can also be adopted to capture long running processes.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: gitmtini:x: kaniughosYou have signed the CLA already but the status is still pending? Let us recheck it.


Hutch-ify the branding

Because this was made from a Hopkins intro to r there's a lot of hopkins branding. Need to switch that over!

I think this is good now? If we add more hutch stuff then we need to get approval from people- up to @avahoffman :)

haha yes! I think this is good. If there are a few random stragglers to address, that's fine :)


Adds ProviderSpec with settings for image and userdata.

The values passed in with the ProviderSpec were previously hard-coded. Any user
of Machines or MachineSets with this controller will need to start including a
suitable ProviderSpec.
fixes #31

This cannot be merged until we fix the installer to include a suitable ProviderSpec. I'd also like to add a few more tests before merging, but feedback would be helpful in the meantime.

This cannot be merged until we fix the installer to include a suitable ProviderSpec. I'd also like to add a few more tests before merging, but feedback would be helpful in the meantime.

On second thought, I don't think we have to worry about this.  It doesn't affect OpenShift until openshift/cluster-api-provider-baremetal merges these changes.
We can go ahead and merge here

Here's a branch with a rebase plus a suggested change to make userdata optional.  Feel free to squash it in if you agree with it.
https://github.com/russellb/cluster-api-provider-baremetal/tree/pr-59


Missing func loadImage(with url: URL)?

The README said RxNuke has this two functions
extension ImagePipeline {
    func loadImage(with url: URL) -> Single<ImageResponse>
    func loadImage(with request: ImageRequest) -> Single<ImageResponse>
}

where is
func loadImage(with url: URL) -> Single<ImageResponse>

Doesn't see it in the source also.
I'm using version 0.5
Just get a little bit confused by the document.
Thanks

Hey, seems that I've forgot to actually add this variant.

Fixed in https://github.com/kean/RxNuke/releases/tag/0.6