GNU bug report logs - #76905
29.4; opening my meetings.org file locks up emacs every time

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: msoulier <at> digitaltorque.ca
Cc: 76905 <at> debbugs.gnu.org
Subject: Re: bug#76905: 29.4;
 opening my meetings.org file locks up emacs every time
Date: Sat, 17 May 2025 11:10:04 +0300

tags 76905 unreproducible moreinfo
close 76905
thanks

> Cc: 76905 <at> debbugs.gnu.org
> Date: Sat, 03 May 2025 10:21:25 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping! Ping! Ping!  Michael, please respond!

No response for more than 2 months, so I'm now closing this bug as
unreproducible.  We can reopen if and when Michael or someone else
provide sufficient data for debugging such problems.

> > Cc: 76905 <at> debbugs.gnu.org
> > Date: Sun, 13 Apr 2025 10:21:49 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > Ping! Ping! Michael, could you please respond with the more complete
> > backtrace, so we could make some progress here?
> > 
> > > Cc: 76905 <at> debbugs.gnu.org
> > > Date: Sat, 29 Mar 2025 14:28:06 +0300
> > > From: Eli Zaretskii <eliz <at> gnu.org>
> > > 
> > > Ping!
> > > 
> > > > Cc: 76905 <at> debbugs.gnu.org
> > > > Date: Tue, 18 Mar 2025 15:09:55 +0200
> > > > From: Eli Zaretskii <eliz <at> gnu.org>
> > > > 
> > > > > 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?
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Previous Next

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