On 10/07/2024 14:58, Eli Zaretskii wrote: >> Date: Wed, 10 Jul 2024 05:46:35 +0300 >> Cc: 71866@debbugs.gnu.org >> From: Dmitry Gutov >> >>>> It does get called. Unfortunately, as soon as I put a breakpoint there, >>>> any attempt to switch to the Emacs window drops into the debugger again >>>> - and I have switch back to the terminal emulator to enter 'c RET' 20 >>>> times or so. >>> >>> I don't think I understand what you are trying to do. I thought you >>> needed to "switch to the Emacs window" just once: to trigger the >>> situation which you want to investigate. Once you trigger it, the >>> debugger will indeed kick in, but all you need to do next is step >>> through the code, so why do you care about switching to Emacs again? >> >> Somehow, the problem manifests when I switch between frames (two frames >> in the current repro) using C-` (bound to `other-frame'). >> >> But if I Alt-Tab to a different application and then Alt-Tab back to >> Emacs, then the glyph is rendered fine - even if the "problematic" frame >> gets selected. > > I thought you see the problem when you switch from another application > to Emacs, not only when you switch between two Emacs frames. I see I > was mistaken. > >>> (gdb) print f >>> $1 = (struct frame *) 0x1234567812345600 >>> (gdb) condition 3 f == 0x1234567812345600 >>> >>> This makes breakpoint 3 trigger only when struct frame variable f has >>> the value of this frame. >> >> So step 1 find out the address of the second frame, step 2 switch to >> first frame, step 3 enable a conditional breakpoint. > > Yes. Okay, I have tried that, and the results might or might not be useful. Similarly to the case of switching from another application, when I have to switch to another application to handle the breakpoints (just typing 'c RET'), the behavior is different. BUT the last call to ns_draw_window_cursor (out of 14) before the control is returned results in the cursor getting hidden (in the new selected Emacs frame only). Unlike the problem I described, the character under the cursor stays drawn, but the cursor rectangle goes away (and that happens after the last breakpoint hit, before that the text and the cursor look correctly - hollow cursor around the character). I'm attaching the last debugging log - maybe the backtrace can be useful? - but note that the backtrace printing is halfway broken as well - it freezes and I have to press ^C a bunch of times to see something. Anyway, while wrong, the behavior is not the same, so I can't be sure it's the same problem that is being triggered.