GNU bug report logs -
#76905
29.4; opening my meetings.org file locks up emacs every time
Previous Next
Full log
View this message in rfc822 format
> Date: Mon, 10 Mar 2025 11:50:24 -0400
> From: "Michael P. Soulier" <msoulier <at> digitaltorque.ca>
> Cc: 76905 <at> debbugs.gnu.org
>
> On 10/03/25 Eli Zaretskii said:
>
> > Instead of killing it, could you attach GDB to it when Emacs "locks
> > up", and then use the procedure described in etc/DEBUG under "If the
> > symptom of the bug is that Emacs fails to respond" to determine where
> > it loops?
> >
> > Or maybe you could post a .org file which triggers this problem
> > without revealing any of your sensitive private information?
>
> I ran git bisect over my config file history until I found out what triggered
> it.
>
> +(load-theme 'modus-vivendi t)
> -(load-theme 'monokai t)
>
> So moving to the modus-vivendi theme and loading my meetings, likely with highly
> indented sections of four levels or more, triggered some kind of font/face look
> up that emacs did not break out of.
>
> I don't have debug symbols, but the function names are in the backtrace.
>
> In xfaces.c...
>
> #0 __pthread_kill_implementation
> (threadid=<optimized out>, signo=signo <at> entry=6, no_tid=no_tid <at> entry=0)
> at ./nptl/pthread_kill.c:44
> #1 0x00007f81126a9f1f in __pthread_kill_internal
> (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
> #2 0x00007f811265afb2 in __GI_raise (sig=sig <at> entry=6)
> at ../sysdeps/posix/raise.c:26
> #3 0x0000558e621d24d5 in terminate_due_to_signal
> (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:464
> #4 0x0000558e621d29f5 in emacs_abort () at sysdep.c:2320
> #5 0x0000558e621d2647 in handle_interrupt (in_signal_handler=<optimized out>)
> at keyboard.c:11504
> #6 0x0000558e62322702 in deliver_process_signal
> (sig=2, handler=0x558e62303220 <handle_interrupt_signal>) at sysdep.c:1741
> #7 0x00007f811265b050 in <signal handler called> ()
> at /lib/x86_64-linux-gnu/libc.so.6
> #8 0x0000558e623a172c in XFIXNUM_RAW (a=<optimized out>)
> at /home/msoulier/tracking/emacs/src/lisp.h:1218
> #9 XFIXNUM (a=<optimized out>)
> at /home/msoulier/tracking/emacs/src/lisp.h:1297
> #10 HASH_INDEX (idx=<optimized out>, h=<optimized out>) at fns.c:4351
> #11 hash_lookup
> (h=h <at> entry=0x558e691be9b8, key=key <at> entry=0x7a974a0, hash=hash <at> entry=0x0)
> at fns.c:4701
> #12 0x0000558e623a1969 in Fgethash
> (key=key <at> entry=0x7a974a0, table=0x558e691be9bd, dflt=dflt <at> entry=0x0)
> at fns.c:5442
> #13 0x0000558e622a0afe in lface_from_face_name_no_resolve
> (f=<optimized out>, face_name=0x7a974a0, signal_p=<optimized out>)
> at xfaces.c:1993
> #14 0x0000558e622a534e in get_lface_attributes_no_remap
> (signal_p=false, attrs=0x7ffffcc12210, face_name=0x7a974a0, f=0x558e691be238) at xfaces.c:2033
> #15 get_lface_attributes
> (w=w <at> entry=0x558e691be488, f=f <at> entry=0x558e691be238, face_name=face_name <at> entry=0x7a974a0, attrs=attrs <at> entry=0x7ffffcc12210, signal_p=signal_p <at> entry=false, named_merge_points=named_merge_points <at> entry=0x7ffffcc12300) at xfaces.c:2084
> #16 0x0000558e622a567e in face_inherited_attr
> (w=w <at> entry=0x558e691be488, f=f <at> entry=0x558e691be238, attrs=attrs <at> entry=0x7ffffcc12320, attr_idx=attr_idx <at> entry=LFACE_EXTEND_INDEX, named_merge_points=named_merge_points <at> entry=0x7ffffcc12300) at xfaces.c:2333
> #17 0x0000558e622a5a6e in merge_named_face
> (w=w <at> entry=0x558e691be488, f=f <at> entry=0x558e691be238, face_name=face_name <at> entry=0x7a974a0, to=to <at> entry=0x7ffffcc127d0, named_merge_points=0x7ffffcc12300,
> named_merge_points <at> entry=0x0, attr_filter=attr_filter <at> entry=LFACE_EXTEND_INDEX) at xfaces.c:2379
> #18 0x0000558e622a40ba in merge_face_ref
Thanks, but this backtrace is incomplete, it seems. Can you post a
complete one?
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.