[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57751: 29.0.50; crash in GC
From: |
Gerd Möllmann |
Subject: |
bug#57751: 29.0.50; crash in GC |
Date: |
Thu, 15 Sep 2022 06:49:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) |
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.