bug#57751: 29.0.50; crash in GC

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Sam Steingold <sds@gnu.org> writes:

> (lldb) 
> frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
>    13263                  mark_object (event->ie.x);
>    13264                  mark_object (event->ie.y);
>    13265                  mark_object (event->ie.frame_or_window);
> -> 13266                  mark_object (event->ie.arg);
>    13267
>    13268                  /* This should never be allocated for a single event, but
>    13269                     mark it anyway in the situation where the list of devices
> (lldb) p event
> warning: could not find Objective-C class data in the process. This may reduce the quality of type information available.
> (buffered_input_event *) $0 = 0x0000000101295c80
> (lldb) p *event
> (buffered_input_event) $1 = {
>   kind = MOVE_FRAME_EVENT
>   ie = {
>     kind = MOVE_FRAME_EVENT
>     part = scroll_bar_nowhere
>     code = 0
>     modifiers = 49116832
>     x = 0xfffffffffffff85e
>     y = 0xffffffffffffe9e6
>     timestamp = 105759277384896
>     frame_or_window = 0x00006210000d9135
>     arg = 0x00007ff7bfee99d0
>     device = 0x00000001021dabaa
>   }

Ok, whatever scroll_bar_nowhere is...

> }
> (lldb) p event->ie.arg
> (Lisp_Object) $2 = 0x00007ff7bfee99d0

Looks like I guess I forgot to tell something.  It's not very important
here, but anyway: The output of 'p' looks a bit different when
emacs_lldb.py has been loaded in LLDB.  And it probably hasn't been
loaded because LLDB requires either a --local-lldbinit command line
flags, or a setting in ~/.lldbinit to load the src/.lldbinit.  The
comment at the start of src/.lldbinit contains instructions.  One can
recognize if emacs_lldb.py has been loaded in LLDB because it prints
something like "I have been loaded" when LLDB is started.

> indeed the crash very often happens when I move the frame (Emacs fails
> to place and size itself properly on startup, so this is the first thing
> I have to do. I keep Emacs maximized - but _not_ full screen).

Ok.

> Another thing is that Tramp appears to be broken recently - it keeps
> timing out even though I can ssh to the remove host without any problems.

You mean this makes startup slower, so that moving the frame manually,
and the crash, don't know, might somehow interfere with/depend on that
delay?  Ok, that might be good hint.  I'll keep it in mind.