GNU bug report logs - #57751
29.0.50; crash in GC

Previous Next

Full log

Message #29 received at 57751 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Sam Steingold <sds <at> gnu.org>
Cc: 57751 <at> debbugs.gnu.org
Subject: Re: bug#57751: 29.0.50; crash in GC
Date: Thu, 15 Sep 2022 06:49:31 +0200

Sam Steingold <sds <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.