GNU bug report logs - #79558
30.2; Searching "^" with apropos can crash emacs

Previous Next

To reply to this bug, email your comments to 79558 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Leander Blume <leander <at> blume.ag>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; Searching "^" with apropos can crash emacs
Date: Thu, 2 Oct 2025 14:06:12 +0200

Dear maintainers,

Reproduced with emacs -Q. Searching for "^" with apropos can crash emacs.
Sometimes, "No library cl-macs in search path" appears in the minibuffer
instead. Quitting and starting again with "emacs -Q" can help with
reproducing.

Here is lldb backtrace output after a crash:

(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7865742e77fbad30)
  * frame #0: 0x000000010015e92c Emacs`print_object + 1204
    frame #1: 0x000000010015bdf4 Emacs`Fprin1 + 112
    frame #2: 0x000000010015d350 Emacs`print_error_message + 616
    frame #3: 0x00000001000c224c Emacs`Fcommand_error_default_function + 252
    frame #4: 0x00000001045eb6d0 help-59d8049f-7ae70ffc.eln`F68656c702d636f6d6d616e642d6572726f722d636f6e66757361626c652d73756767657374696f6e73_help_command_error_confusable_suggestions_0 + 36
    frame #5: 0x0000000100139ea0 Emacs`Ffuncall + 324
    frame #6: 0x00000001000c211c Emacs`cmd_error_internal + 156
    frame #7: 0x00000001000c373c Emacs`cmd_error + 376
    frame #8: 0x000000010013bef0 Emacs`internal_condition_case + 84
    frame #9: 0x00000001000c231c Emacs`command_loop_2 + 52
    frame #10: 0x000000010013b86c Emacs`internal_catch + 88
    frame #11: 0x0000000100201e28 Emacs`command_loop.cold.1 + 88
    frame #12: 0x00000001000c1cc0 Emacs`command_loop + 156
    frame #13: 0x00000001000c1b70 Emacs`recursive_edit_1 + 168
    frame #14: 0x00000001000c1de0 Emacs`Frecursive_edit + 264
    frame #15: 0x00000001000c0e3c Emacs`main + 6924
    frame #16: 0x000000018a942b98 dyld`start + 6076
  thread #2, name = 'gmain'
    frame #0: 0x000000018acacc2c libsystem_kernel.dylib`__select + 8
    frame #1: 0x00000001019db1e0 libglib-2.0.0.dylib`g_poll + 436
    frame #2: 0x00000001019cd71c libglib-2.0.0.dylib`g_main_context_iterate_unlocked + 380
    frame #3: 0x00000001019cd7e4 libglib-2.0.0.dylib`g_main_context_iteration + 60
    frame #4: 0x00000001019ce778 libglib-2.0.0.dylib`glib_worker_main + 48
    frame #5: 0x00000001019f15b4 libglib-2.0.0.dylib`g_thread_proxy + 84
    frame #6: 0x000000018ace3c0c libsystem_pthread.dylib`_pthread_start + 136
  thread #3
    frame #0: 0x000000018aca38b0 libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #4
    frame #0: 0x000000018aca38b0 libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #5
    frame #0: 0x000000018aca38b0 libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #6
    frame #0: 0x000000018aca38b0 libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #8
    frame #0: 0x0000000000000000
  thread #9
    frame #0: 0x000000018aca7e90 libsystem_kernel.dylib`__pselect + 8
    frame #1: 0x000000018aca7d68 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
    frame #2: 0x00000001001d1e10 Emacs`-[EmacsApp fd_handler:] + 184
    frame #3: 0x000000018c396ba8 Foundation`__NSThread__start__ + 732
    frame #4: 0x000000018ace3c0c libsystem_pthread.dylib`_pthread_start + 136
  thread #10, name = 'com.apple.NSEventThread'
    frame #0: 0x000000018aca1c34 libsystem_kernel.dylib`mach_msg2_trap + 8
    frame #1: 0x000000018acb43a0 libsystem_kernel.dylib`mach_msg2_internal + 76
    frame #2: 0x000000018acaa764 libsystem_kernel.dylib`mach_msg_overwrite + 484
    frame #3: 0x000000018aca1fa8 libsystem_kernel.dylib`mach_msg + 24
    frame #4: 0x000000018adcecbc CoreFoundation`__CFRunLoopServiceMachPort + 160
    frame #5: 0x000000018adcd5d8 CoreFoundation`__CFRunLoopRun + 1208
    frame #6: 0x000000018adcca98 CoreFoundation`CFRunLoopRunSpecific + 572
    frame #7: 0x000000018ee1578c AppKit`_NSEventThread + 140
    frame #8: 0x000000018ace3c0c libsystem_pthread.dylib`_pthread_start + 136

In GNU Emacs 30.2 (build 2, aarch64-apple-darwin24.6.0, NS
appkit-2575.70 Version 15.6 (Build 24G84)) of 2025-09-04 built on
Leanders-MacBook-Pro
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.6.1

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
--infodir=/opt/homebrew/Cellar/emacs-plus <at> 30/30.2/share/info/emacs
--prefix=/opt/homebrew/Cellar/emacs-plus <at> 30/30.2
--with-native-compilation=aot --with-xml2 --with-gnutls
--without-compress-install --without-dbus --without-imagemagick
--with-modules --with-rsvg --with-webp --with-ns
--disable-ns-self-contained 'CFLAGS=-O2 -DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT -I/opt/homebrew/opt/sqlite/include
-I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include'
'LDFLAGS=-L/opt/homebrew/opt/sqlite/lib -L/opt/homebrew/lib/gcc/15
-I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY
KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 49045 9702) (symbols 48 5274 0) (strings 32 13512 2577)
(string-bytes 1 405288) (vectors 16 9136)
(vector-slots 8 130034 12968) (floats 8 22 13) (intervals 56 266 6)
(buffers 992 10))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leander Blume <leander <at> blume.ag>
Cc: 79558 <at> debbugs.gnu.org
Subject: Re: bug#79558: 30.2; Searching "^" with apropos can crash emacs
Date: Thu, 02 Oct 2025 18:54:27 +0300

> From: Leander Blume <leander <at> blume.ag>
> Date: Thu, 2 Oct 2025 14:06:12 +0200
> 
> Dear maintainers,
> 
> Reproduced with emacs -Q. Searching for "^" with apropos can crash emacs.
> Sometimes, "No library cl-macs in search path" appears in the minibuffer
> instead. Quitting and starting again with "emacs -Q" can help with
> reproducing.
> 
> Here is lldb backtrace output after a crash:
> 
> (lldb) bt all
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7865742e77fbad30)
>   * frame #0: 0x000000010015e92c Emacs`print_object + 1204
>     frame #1: 0x000000010015bdf4 Emacs`Fprin1 + 112
>     frame #2: 0x000000010015d350 Emacs`print_error_message + 616
>     frame #3: 0x00000001000c224c Emacs`Fcommand_error_default_function + 252

I cannot reproduce this, but I think we saw problems with this code
and solved (or at least improved it) on the master branch.  Can you
try building the master branch of the Emacs Git repository?  If so,
could you try your recipe with that version and see if the problem
persists?

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Leander Blume <leander <at> blume.ag>
Cc: 79558 <at> debbugs.gnu.org
Subject: Re: bug#79558: 30.2; Searching "^" with apropos can crash emacs
Date: Thu, 02 Oct 2025 20:01:47 +0000

"Leander Blume" <leander <at> blume.ag> writes:

> Dear maintainers,
>
> Reproduced with emacs -Q. Searching for "^" with apropos can crash emacs.
> Sometimes, "No library cl-macs in search path" appears in the minibuffer
> instead. Quitting and starting again with "emacs -Q" can help with
> reproducing.

I cannot reproduce this (on GNU/Linux, on the emacs-30 branch), though I
do see the "No library cl-macs..."  message.

However, bug#74966 comes to mind: in that bug, we stored the wrong
docstring in nativecomp functions that share a name with an internal
DEFUN. IIRC, the problem was specific to non-GNU/Linux systems, and
would result in random memory being accessed, so it could explain this
crash. I don't think the fix has been applied to the emacs-30 branch.

As an experiment, I added this to x-win.el:

(defun x-file-dialog (prompt dir &optional default-filename
                             mustmatch only-dir-p)
  "SKIP: real doc in xfns.c."
  (ns-read-file-name prompt dir mustmatch default-filename only-dir-p))

and ran

./src/emacs -Q --eval '(progn (apropos "^") (kill-emacs))'

a few times, and I did see random crashes. So this seems plausible to
me.

Do we want to backport the fix or maybe just install a simple stop-gap
which exits early rather than corrupting data?

> Here is lldb backtrace output after a crash:
>
> (lldb) bt all
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7865742e77fbad30)

That reads "0\xad\xfbw.tex". The second half, at least, looks like it's
ASCII data. The first half doesn't, though, and is invalid UTF-8.

The entire backtrace looks like we died printing the error data after an
error. If it still happens on the master branch, we should investigate
what that error is about.

Pip

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: leander <at> blume.ag, 79558 <at> debbugs.gnu.org
Subject: Re: bug#79558: 30.2; Searching "^" with apropos can crash emacs
Date: Fri, 03 Oct 2025 09:26:01 +0300

> Cc: 79558 <at> debbugs.gnu.org
> Date: Thu, 02 Oct 2025 20:01:47 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> As an experiment, I added this to x-win.el:
> 
> (defun x-file-dialog (prompt dir &optional default-filename
>                              mustmatch only-dir-p)
>   "SKIP: real doc in xfns.c."
>   (ns-read-file-name prompt dir mustmatch default-filename only-dir-p))
> 
> and ran
> 
> ./src/emacs -Q --eval '(progn (apropos "^") (kill-emacs))'
> 
> a few times, and I did see random crashes. So this seems plausible to
> me.
> 
> Do we want to backport the fix or maybe just install a simple stop-gap
> which exits early rather than corrupting data?

As long as we don't plan any further releases from the emacs-30 branch
(and we don't ATM), I see no reason to backport this there.

> The entire backtrace looks like we died printing the error data after an
> error. If it still happens on the master branch, we should investigate
> what that error is about.

Agreed.

Thanks.

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

From: Leander Blume <leander <at> blume.ag>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79558 <at> debbugs.gnu.org
Subject: Re: bug#79558: 30.2; Searching "^" with apropos can crash emacs
Date: Fri, 3 Oct 2025 18:17:17 +0200

[Message part 1 (text/plain, inline)]

I could not reproduce the crash or the message on the master branch.

> On 2. Oct 2025, at 17:54, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Leander Blume <leander <at> blume.ag>
>> Date: Thu, 2 Oct 2025 14:06:12 +0200
>> 
>> Dear maintainers,
>> 
>> Reproduced with emacs -Q. Searching for "^" with apropos can crash emacs.
>> Sometimes, "No library cl-macs in search path" appears in the minibuffer
>> instead. Quitting and starting again with "emacs -Q" can help with
>> reproducing.
>> 
>> Here is lldb backtrace output after a crash:
>> 
>> (lldb) bt all
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7865742e77fbad30)
>>  * frame #0: 0x000000010015e92c Emacs`print_object + 1204
>>    frame #1: 0x000000010015bdf4 Emacs`Fprin1 + 112
>>    frame #2: 0x000000010015d350 Emacs`print_error_message + 616
>>    frame #3: 0x00000001000c224c Emacs`Fcommand_error_default_function + 252
> 
> I cannot reproduce this, but I think we saw problems with this code
> and solved (or at least improved it) on the master branch.  Can you
> try building the master branch of the Emacs Git repository?  If so,
> could you try your recipe with that version and see if the problem
> persists?

[Message part 2 (text/html, inline)]

Message #22 received at 79558-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leander Blume <leander <at> blume.ag>
Cc: 79558-done <at> debbugs.gnu.org
Subject: Re: bug#79558: 30.2; Searching "^" with apropos can crash emacs
Date: Sat, 11 Oct 2025 11:53:27 +0300

> From: Leander Blume <leander <at> blume.ag>
> Date: Fri, 3 Oct 2025 18:17:17 +0200
> Cc: 79558 <at> debbugs.gnu.org
> 
> I could not reproduce the crash or the message on the master branch.

Thanks.  So I assume this was already solved, and I'm therefore
closing this bug.

Previous Next

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