GNU bug report logs - #56443
28.1; Mac segmentation fault with ffap

Previous Next

Package: emacs;

Reported by: Stephen Eglen <sje30 <at> cam.ac.uk>

Date: Thu, 7 Jul 2022 17:23:02 UTC

Severity: normal

Found in version 28.1

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 56443 <at> debbugs.gnu.org, sje30 <at> cam.ac.uk
Subject: bug#56443: 28.1; Mac segmentation fault with ffap
Date: Fri, 08 Jul 2022 08:39:49 +0300
> Cc: 56443 <at> debbugs.gnu.org
> Date: Thu, 07 Jul 2022 22:36:53 +0200
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Stephen Eglen <sje30 <at> cam.ac.uk> writes:
> 
> > Can anyone replicate the following on Mac M1?  I'm using the 'emacs'
> > cask from homebrew, and I get the crash both with GUI and terminal
> > version of Emacs.  This seems to be mac-specific; I do not see the
> > problem on linux.
> >
> 
> Yes, I can reproduce the crash.  Attaching a debugger I see that the
> filename passed through file-name-case-insensitive-p is NULL:
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x4)
>   * frame #0: 0x0000000100d61c2c emacs`STRING_MULTIBYTE(str=0x0000000000000000) at lisp.h:1613:34
>     frame #1: 0x0000000100d64f68 emacs`encode_file_name_1(fname=0x0000000000000000) at coding.c:10397:8
>     frame #2: 0x0000000100d64f28 emacs`encode_file_name(fname=0x0000000000000000) at coding.c:10419:25
>     frame #3: 0x0000000100e2e098 emacs`file_name_case_insensitive_err(file=0x0000000000000000) at fileio.c:2555:28
>     frame #4: 0x0000000100e2dfcc emacs`Ffile_name_case_insensitive_p(filename=0x0000000000000000) at fileio.c:2600:17
>     frame #5: 0x0000000100ec47ac emacs`funcall_subr(subr=0x0000000101083bb8, numargs=1, args=0x0000000138058580) at eval.c:2996:15

That's not NULL, that's nil (which is represented as zero).

But I don't understand how could that happen, because
Ffile_name_case_insensitive_p checks the argument for validity:

  DEFUN ("file-name-case-insensitive-p", Ffile_name_case_insensitive_p,
	 Sfile_name_case_insensitive_p, 1, 1, 0,
	 doc: /* Return t if file FILENAME is on a case-insensitive filesystem.
  Return nil if FILENAME does not exist or is not on a case-insensitive
  filesystem, or if there was trouble determining whether the filesystem
  is case-insensitive.  */)
    (Lisp_Object filename)
  {
    Lisp_Object handler;

    CHECK_STRING (filename);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
    filename = Fexpand_file_name (filename, Qnil);

So it seems like expand-file-name returned nil in this case?

Can someone step through the code, including stepping into
Fexpand_file_name, and see  how we get that nil in this case?

(I tried to reproduce on my system, which is not a Mac, but I don't
see any nil filenames in that case.)




This bug report was last modified 3 years and 13 days ago.

Previous Next


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