Package: emacs;
Reported by: Sean Devlin <spd <at> toadstyle.org>
Date: Mon, 28 Jul 2025 18:32:01 UTC
Severity: normal
Found in version 31.0.50
View this message in rfc822 format
From: Sean Devlin <spd <at> toadstyle.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 79116 <at> debbugs.gnu.org Subject: bug#79116: 31.0.50; Crash on IGC build Date: Wed, 30 Jul 2025 16:11:57 -0500
Hi Eli,
> On Jul 30, 2025, at 6:24 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> From: Sean Devlin <spd <at> toadstyle.org>
>> Date: Mon, 28 Jul 2025 13:31:08 -0500
>>
>> I left Emacs idle overnight, and I found a crash log when I returned in
>> the morning. Please see the attached file.
>>
>> I'm using the IGC branch, and it looks like a related assertion failed.
>>
>> I have igc-step-interval set to 0.05, but no other configuration related to GC.
>>
>> I don’t know how to reproduce the error.
>
> Can you tell what code could your Emacs be running while idle? Like,
> timers etc.?
Here are the timers I have running:
5.0s 5.0s auto-revert-buffers
2m 0.6s 5m savehist-autosave
22m 14.7s 1h org-persist--refresh-gc-lock
* 0.1s t show-paren-function
* 0.5s t which-func-update
* 0.5s t jit-lock-context--update
* 0.5s :repeat blink-cursor-start
* 4h 0m 0.0s repeat ef-themes-load-random
The last one might be relevant, since I added it within the last week. Basically, it is choosing a new theme after Emacs has been idle for four hours. This entails disabling the currently enabled theme and then enabling a new one.
>
>> Thread 0:: Dispatch queue: com.apple.main-thread
>> 0 Emacs 0x100863214 redisplay_internal + 208
>> 1 Emacs 0x10086930c redisplay_preserve_echo_area + 132
>> 2 Emacs 0x100914d5c detect_input_pending_run_timers + 144
>> 3 Emacs 0x1009f4520 wait_reading_process_output + 4488
>> 4 Emacs 0x100912bb4 read_char + 7444
>> 5 Emacs 0x10090ee14 read_key_sequence + 1328
>> 6 Emacs 0x10090d2c8 command_loop_1 + 864
>> 7 Emacs 0x100992c14 internal_condition_case + 228
>> 8 Emacs 0x10090cf54 command_loop_2 + 52
>> 9 Emacs 0x100992218 internal_catch + 224
>> 10 Emacs 0x100aecd94 command_loop.cold.1 + 88
>> 11 Emacs 0x10090c784 command_loop + 156
>> 12 Emacs 0x10090c618 recursive_edit_1 + 188
>> 13 Emacs 0x10090c91c Frecursive_edit + 384
>> 14 Emacs 0x10090b73c main + 8644
>> 15 dyld 0x183686b98 start + 6076
>>
>> Thread 1 Crashed:
>> 0 libsystem_kernel.dylib 0x1839ee388 __pthread_kill + 8
>> 1 libsystem_pthread.dylib 0x183a2788c pthread_kill + 296
>> 2 libsystem_c.dylib 0x1838f8d04 raise + 32
>> 3 Emacs 0x100aec8d4 terminate_due_to_signal + 120
>> 4 Emacs 0x100aed748 emacs_abort + 20
>> 5 Emacs 0x100a4a2a0 ns_term_shutdown + 132
>> 6 Emacs 0x10090951c shut_down_emacs + 360
>> 7 Emacs 0x100aec938 terminate_due_to_signal + 220
>> 8 Emacs 0x100a1d150 igc_assert_fail + 76
>> 9 Emacs 0x100ae1b50 mps_lib_assert_fail + 32 (mpsliban.c:87) [inlined]
>> 10 Emacs 0x100ae1b50 traceScanSegRes + 532 (trace.c:1229)
>> 11 Emacs 0x100aa30e4 traceScanSeg + 40 (trace.c:1267)
>> 12 Emacs 0x100aa2f64 TraceSegAccess + 328 (trace.c:1320)
>> 13 Emacs 0x100aa84f8 SegWholeAccess + 336 (seg.c:1262)
>> 14 Emacs 0x100a96d44 ArenaAccess + 564 (global.c:671)
>> 15 Emacs 0x100ae9300 protCatchOne + 192 (protxc.c:242) [inlined]
>> 16 Emacs 0x100ae9300 protCatchThread + 304 (protxc.c:284)
>> 17 libsystem_pthread.dylib 0x183a27c0c _pthread_start + 136
>> 18 libsystem_pthread.dylib 0x183a22b80 thread_start + 8
>
> This indicates that thread 1 was the thread which got hit by SIGABRT.
> Thread 1 is NOT the main thread, which runs Lisp and redisplay. So
> what is thread 1, and how come it calls MPS functions?
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.