GNU bug report logs - #56853
29.0.50; MacOS installation broken

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sun, 31 Jul 2022 12:36:02 UTC

Severity: normal

Merged with 56871

Found in versions 28.1, 29.0.50

Fixed in version 29.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Andrea Corallo <akrl <at> sdf.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 09:51:24 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Don't know if this is helpful.  Alas, I'm not quite on top of what's
> going on in master.
>
> Apparently, the error is signaled from C:
>
> (lldb) xbacktrace 
> (unsigned char *) data = 0x00000001030ab538 "file-name-sans-extension"
> (unsigned char *) data = 0x0000000100284848 "defalias"
> (unsigned char *) data = 0x000000010028a02f "load"
> (unsigned char *) data = 0x000000010028a02f "load"
>
>
>  frame #0: 0x0000000100258b78 Emacs`Fsignal(error_symbol=-> (struct Lisp_Symbol *) $2 = 0x00000001006a1a50, data=-> (EMACS_INT) $4 = 1086473292) at eval.c:1687:27 [opt]
>    1684	  (Lisp_Object error_symbol, Lisp_Object data)
>    1685	{
>    1686	  /* If they call us with nonsensical arguments, produce "peculiar error".  */
> -> 1687	  if (NILP (error_symbol) && NILP (data))
>    1688	    error_symbol = Qerror;
>    1689	  signal_or_quit (error_symbol, data, false);
>    1690	  eassume (false);
> Target 0: (Emacs) stopped.
> (lldb) up
> frame #1: 0x0000000100258bb0 Emacs`xsignal(error_symbol=<unavailable>, data=<unavailable>) at lisp.h:4550:3 [opt]
>    4547	INLINE AVOID
>    4548	xsignal (Lisp_Object error_symbol, Lisp_Object data)
>    4549	{
> -> 4550	  Fsignal (error_symbol, data);
>    4551	}
>    4552	extern AVOID xsignal0 (Lisp_Object);
>    4553	extern AVOID xsignal1 (Lisp_Object, Lisp_Object);
> (lldb) 
> frame #2: 0x0000000100258988 Emacs`xsignal1(error_symbol=<unavailable>, arg=<unavailable>) at eval.c:0:26 [opt]
>    1844	}
>    1845	
>    1846	void
> -> 1847	xsignal1 (Lisp_Object error_symbol, Lisp_Object arg)
>    1848	{
>    1849	  xsignal (error_symbol, list1 (arg));
>    1850	}
> Note: this address is compiler-generated code in function xsignal1 that has no source code associated with it.
> (lldb) 
>
> frame #3: 0x000000010016fb80 Emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:2912:2 [opt]
>    2909	  else
>    2910	    {
>    2911	      if (NILP (fun))
> -> 2912		xsignal1 (Qvoid_function, original_fun);
>    2913	      if (!CONSP (fun))
>    2914		xsignal1 (Qinvalid_function, original_fun);
>    2915	      Lisp_Object funcar = XCAR (fun);
> (lldb) 
> frame #4: 0x000000010016c368 Emacs`Ffuncall(nargs=2, args=-> (struct Lisp_Symbol *) $64 = 0x0000000100691a30) at eval.c:2958:21 [opt]
>    2955	  if (debug_on_next_call)
>    2956	    do_debug_on_call (Qlambda, count);
>    2957	
> -> 2958	  Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
>    2959	
>    2960	  lisp_eval_depth--;
>    2961	  if (backtrace_debug_on_exit (specpdl_ref_to_ptr (count)))
> (lldb) 
> frame #5: 0x00000001001c0b88 Emacs`maybe_defer_native_compilation(function_name=-> (struct Lisp_Symbol *) $67 = 0x00000001100082c0, definition=-> (struct Lisp_Vector *) $72 = 0x000000011000d5a8) at comp.c:5120:14 [opt]
>    5117	    return;
>    5118	
>    5119	  Lisp_Object src =
> -> 5120	    concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
>    5121		     build_pure_c_string (".el"));
>    5122	  if (NILP (Ffile_exists_p (src)))
>    5123	    {

I think what is going on is that while starting we get into
'maybe_defer_native_compilation' where we try to call
`file-name-sans-extension' but this is stil not defined for some reason.
Now why this condition happen has still to be determined.

Perhaps someone should compare this startup sequence with the working
non moved binary?

Thanks

  Andrea




This bug report was last modified 2 years and 346 days ago.

Previous Next


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