bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization

[Dmitry Gutov]

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 <dmitry@gutov.dev>
> >
> > > > 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.

emacs-lldb-log.txt
Description: Text document