GNU bug report logs - #51689
emacs -nw under native-compilation errors out

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51689 in the body.
You can then email your comments to 51689 AT debbugs.gnu.org in the normal way.

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

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

From: Han Boetes <han <at> boetes.org>
To: bug-gnu-emacs <at> gnu.org
Subject: emacs
Date: Mon, 8 Nov 2021 17:44:54 +0100

I compiled emacs with native compilation on OpenBSD-7.0 amd64 like this:

    export CC=egcc \
           CPP="ecpp" \
           CPPFLAGS="-I/usr/local/include" \
           LDFLAGS="-L/usr/local/lib"
    ./autogen.sh
    ./configure --without-makeinfo --without-x --mandir=/usr/local/man --with-native-compilation
    gmake

egcc (GCC) 11.2.0, is just gcc-11 which is traditionally installed as
egcc to avoid conflicts with the usually somewhat older gcc in base.


Now if I start emacs with:

    emacs -nw -Q ~/.config/emacs/init.el

The file init.el is not loaded and I get a single error message:

    Symbol’s function definition is void: regexp-opt-group

After which emacs works OK, for example c-x c-f ~/.config/emacs/init.el works as expected.

Then I recompiled emacs without native compilation and the error did not occur.

And now to make the case even more mysterious, if I start emacs normally, like:

    emacs -nw ~/.config/emacs/init.el

Everything works fine. I accidentally discovered the problem by
running emacs as a test user without configuration.


Please let me know if there is anything I can do to help debugging this problem.


# Han

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Mon, 08 Nov 2021 20:15:56 +0200

> Date: Mon, 8 Nov 2021 17:44:54 +0100
> From: Han Boetes <han <at> boetes.org>
> 
>     ./configure --without-makeinfo --without-x --mandir=/usr/local/man --with-native-compilation
>     gmake
> 
> egcc (GCC) 11.2.0, is just gcc-11 which is traditionally installed as
> egcc to avoid conflicts with the usually somewhat older gcc in base.
> 
> 
> Now if I start emacs with:
> 
>     emacs -nw -Q ~/.config/emacs/init.el
> 
> The file init.el is not loaded and I get a single error message:
> 
>     Symbol’s function definition is void: regexp-opt-group

Yes, "emacs -nw" doesn't start well yet under native-compilation.
This is being discussed on emacs-devel for the past couple of weeks,
so stay tuned.

> Please let me know if there is anything I can do to help debugging this problem.

You could find the reason and suggest the solution. ;-)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Sun, 14 Nov 2021 21:26:09 +0200

> Date: Mon, 8 Nov 2021 17:44:54 +0100
> From: Han Boetes <han <at> boetes.org>
> 
> I compiled emacs with native compilation on OpenBSD-7.0 amd64 like this:
> 
>     export CC=egcc \
>            CPP="ecpp" \
>            CPPFLAGS="-I/usr/local/include" \
>            LDFLAGS="-L/usr/local/lib"
>     ./autogen.sh
>     ./configure --without-makeinfo --without-x --mandir=/usr/local/man --with-native-compilation
>     gmake
> 
> egcc (GCC) 11.2.0, is just gcc-11 which is traditionally installed as
> egcc to avoid conflicts with the usually somewhat older gcc in base.
> 
> 
> Now if I start emacs with:
> 
>     emacs -nw -Q ~/.config/emacs/init.el
> 
> The file init.el is not loaded and I get a single error message:
> 
>     Symbol’s function definition is void: regexp-opt-group

Please try the latest emacs-28 branch, I hope this problem is now
fixed.  But you will need to perform a complete bootstrap.

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

From: Han Boetes <han <at> boetes.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Sun, 14 Nov 2021 22:20:19 +0100

Eli Zaretskii wrote:
> Please try the latest emacs-28 branch, I hope this problem is now
> fixed.  But you will need to perform a complete bootstrap.

Hello Eli,

I just tried running emacs -Q -nw with the latest bootstrapped emacs
from the emacs-28 branch and I got the same message:

  Symbol's function definition is void: regexp-opt-group

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Mon, 15 Nov 2021 14:33:33 +0200

> Date: Sun, 14 Nov 2021 22:20:19 +0100
> From: Han Boetes <han <at> boetes.org>
> Cc: 51689 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > Please try the latest emacs-28 branch, I hope this problem is now
> > fixed.  But you will need to perform a complete bootstrap.
> 
> Hello Eli,
> 
> I just tried running emacs -Q -nw with the latest bootstrapped emacs
> from the emacs-28 branch and I got the same message:
> 
>   Symbol's function definition is void: regexp-opt-group

Is it "emacs -Q -nw" or "emacs -Q -nw ~/.config/emacs/init.el", as you
reported in your original report?  If the latter, we need to take a
closer look at your init.el: can you find which part of it triggers
this, and post that part?

If "emacs -nw -Q" already triggers the error, please tell what is the
terminal file from lisp/term/ that Emacs loads on your system.  Also,
please show the output of evaluating the following variables in
*scratch*:

 features
 load-history

(Evaluating them will by default show ellipsis: type RET on that
ellipsis to show the full value.)

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

From: Han Boetes <han <at> boetes.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Tue, 16 Nov 2021 10:22:42 +0100

I reverted back to 29.0.50, I'll gladly reinstall 28.0 as soon as I know
how to get the requested info.

Eli Zaretskii wrote:
> Is it "emacs -Q -nw" or "emacs -Q -nw ~/.config/emacs/init.el", as you
> reported in your original report?  If the latter, we need to take a
> closer look at your init.el: can you find which part of it triggers
> this, and post that part?

Both of them, and with all files, my init.el was just an example.

> If "emacs -nw -Q" already triggers the error, please tell what is the
> terminal file from lisp/term/ that Emacs loads on your system.

How can I find that information?


> Also, please show the output of evaluating the following variables in
> *scratch*:
> 
>  features

I used c-h v features to get this output, is that what you meant? If not, please help me getting the requested information.

(thingatpt help-fns radix-tree comp-cstr warnings rx cl-seq cl-macs cl-extra help-mode tool-bar seq gv subr-x byte-opt cl-loaddefs cl-lib bytecomp byte-compile cconv iso-tra\
nsl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-ba\
r menu-bar rfn-eshadow isearch easymenu timer select mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic 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 chars\
cript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay\
 sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind kqueue lcms2 multi-tty make-network-process native-compile emac\
s)


>  load-history

> (Evaluating them will by default show ellipsis: type RET on that
> ellipsis to show the full value.)



# Han

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Tue, 16 Nov 2021 15:24:03 +0200

> Date: Tue, 16 Nov 2021 10:22:42 +0100
> From: Han Boetes <han <at> boetes.org>
> Cc: 51689 <at> debbugs.gnu.org
> 
> > Is it "emacs -Q -nw" or "emacs -Q -nw ~/.config/emacs/init.el", as you
> > reported in your original report?  If the latter, we need to take a
> > closer look at your init.el: can you find which part of it triggers
> > this, and post that part?
> 
> Both of them, and with all files, my init.el was just an example.

Even with an empty .el file?  What about just "emacs -Q -nw"?

> > If "emacs -nw -Q" already triggers the error, please tell what is the
> > terminal file from lisp/term/ that Emacs loads on your system.
> 
> How can I find that information?

It should be one of features mentioned in the value of 'features'.

Also, "M-: (tty-type) RET" should show the terminal type, and that
determines the terminal file Emacs loads.

> >  features
> 
> I used c-h v features to get this output, is that what you meant? If not, please help me getting the requested information.

Is this in "emacs -Q -nw"?  There should be a feature defined by some
file from lisp/term/ loaded for the terminal support, but I see no
such feature.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: han <at> boetes.org
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Wed, 17 Nov 2021 19:45:17 +0200

Ping!  Any progress there?

I'd also like to say that the only file that mentions regexp-opt-group
is regexp-opt.el itself.  So I tend to think that you have an old
regexp-opt.el/elc somewhere on your system, and that gets in the way.
Or maybe regexp-opt.el is miscompiled for some reason.

> Date: Tue, 16 Nov 2021 15:24:03 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 51689 <at> debbugs.gnu.org
> 
> > Date: Tue, 16 Nov 2021 10:22:42 +0100
> > From: Han Boetes <han <at> boetes.org>
> > Cc: 51689 <at> debbugs.gnu.org
> > 
> > > Is it "emacs -Q -nw" or "emacs -Q -nw ~/.config/emacs/init.el", as you
> > > reported in your original report?  If the latter, we need to take a
> > > closer look at your init.el: can you find which part of it triggers
> > > this, and post that part?
> > 
> > Both of them, and with all files, my init.el was just an example.
> 
> Even with an empty .el file?  What about just "emacs -Q -nw"?
> 
> > > If "emacs -nw -Q" already triggers the error, please tell what is the
> > > terminal file from lisp/term/ that Emacs loads on your system.
> > 
> > How can I find that information?
> 
> It should be one of features mentioned in the value of 'features'.
> 
> Also, "M-: (tty-type) RET" should show the terminal type, and that
> determines the terminal file Emacs loads.
> 
> > >  features
> > 
> > I used c-h v features to get this output, is that what you meant? If not, please help me getting the requested information.
> 
> Is this in "emacs -Q -nw"?  There should be a feature defined by some
> file from lisp/term/ loaded for the terminal support, but I see no
> such feature.
> 
> 
> 
> 

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

From: Han Boetes <han <at> boetes.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Wed, 17 Nov 2021 21:45:40 +0100

Eli Zaretskii wrote:
> Ping!  Any progress there?

Hi there, I was very busy, but not to worry, I haven't forgotten. I will
get to your previous E-Mail right after this one.

> I'd also like to say that the only file that mentions regexp-opt-group
> is regexp-opt.el itself.  So I tend to think that you have an old
> regexp-opt.el/elc somewhere on your system, and that gets in the way.
> Or maybe regexp-opt.el is miscompiled for some reason.

 - I locate(1) regexp-opt.el and found no instances in unexpected places.
 - I rsync'ed the git repo from the Linux to the OpenBSD host and recompiled, that didn't help.
 - Without native-comp this problem does not occur.
 



# Han

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

From: Han Boetes <han <at> boetes.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Wed, 17 Nov 2021 22:41:11 +0100

Eli Zaretskii wrote:
> > Date: Tue, 16 Nov 2021 10:22:42 +0100
> > From: Han Boetes <han <at> boetes.org>
> > Cc: 51689 <at> debbugs.gnu.org
> > 
> > > Is it "emacs -Q -nw" or "emacs -Q -nw ~/.config/emacs/init.el", as you
> > > reported in your original report?  If the latter, we need to take a
> > > closer look at your init.el: can you find which part of it triggers
> > > this, and post that part?
> > 
> > Both of them, and with all files, my init.el was just an example.
> 
> Even with an empty .el file?  What about just "emacs -Q -nw"?

It all results in the same error.
 
> > > If "emacs -nw -Q" already triggers the error, please tell what is the
> > > terminal file from lisp/term/ that Emacs loads on your system.
> > 
> > How can I find that information?
> 
> It should be one of features mentioned in the value of 'features'.
> 
> Also, "M-: (tty-type) RET" should show the terminal type, and that
> determines the terminal file Emacs loads.

I get this with screen-256color, but also with xterm-256color and xterm.
Depending on how I logged on.
 
> > >  features
> > 
> > I used c-h v features to get this output, is that what you meant? If not, please help me getting the requested information.
> 
> Is this in "emacs -Q -nw"?  There should be a feature defined by some
> file from lisp/term/ loaded for the terminal support, but I see no
> such feature.

I still don't understand how I should provide the requested features.
Could you elaborate on that?


I just searched a bit further, it also happens with "emacs -nw
some-file" when there is no .emacs file present, or if it contains only:

    (custom-set-variables)

But if that .emacs contains just one setting like this:

    (custom-set-variables '(auto-insert-mode t))

The problem is gone. Fascinating!

So to summarize:

emacs -nw -Q some-file, shows "Symbol's function definition is void: regexp-opt-group", does not load some-file
emacs -nw -Q          , shows "Symbol's function definition is void: regexp-opt-group"

In both cases, I can continue working.


# Han

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Thu, 18 Nov 2021 09:13:04 +0200

> Date: Wed, 17 Nov 2021 22:41:11 +0100
> From: Han Boetes <han <at> boetes.org>
> Cc: 51689 <at> debbugs.gnu.org
> 
> > > >  features
> > > 
> > > I used c-h v features to get this output, is that what you meant? If not, please help me getting the requested information.
> > 
> > Is this in "emacs -Q -nw"?  There should be a feature defined by some
> > file from lisp/term/ loaded for the terminal support, but I see no
> > such feature.
> 
> I still don't understand how I should provide the requested features.
> Could you elaborate on that?

  . emacs -Q -nw
  . in *scratch* type "features" (without the quotes)
  . go to the end of "features", after the final 's', and type C-j
  . if the list Emacs inserts into the buffer has ellipsis in it, go
    to that ellipsis and type RET
  . post the resulting list here

> I just searched a bit further, it also happens with "emacs -nw
> some-file" when there is no .emacs file present, or if it contains only:
> 
>     (custom-set-variables)
> 
> But if that .emacs contains just one setting like this:
> 
>     (custom-set-variables '(auto-insert-mode t))
> 
> The problem is gone. Fascinating!

I think at this point only running under a debugger will help us
efficiently.  So please act according to the instructions below, and
show the backtrace it produces:

  $ cd /path/to/emacs/src/
  $ gdb ./emacs
  GNU gdb (GDB) 11.1
  Copyright (C) 2021 Free Software Foundation, Inc.
  ...
  (gdb) source ./.gdbinit
  (gdb) break Fsignal
  (gdb) commands
  Type commands for breakpoint(s) 2, one per line.
  End with a line saying just "end".
  > pp error_symbol
  > pp data
  > end
  (gdb) run -Q -nw

When the breakpoint breaks, look at the error_symbol and data printed
by GDB; if the symbol are not "void-function", type "continue" at
GDB's prompt to run Emacs further.  When you eventually get symbol as
"void-function" and data that mentions regexp-opt-group, type:

  (gdb) thread apply all bt

This should produce both C-level backtrace and Lisp-level backtrace of
all the threads in Emacs.  Please post that here in its entirety.

(I hope you have GDB installed; if not, please install it.)

Thanks.

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

From: Han Boetes <han <at> boetes.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Fri, 19 Nov 2021 23:18:04 +0100

Another thing I noticed: if there is a valid ~/.config/emacs/init.el,
emacs -nw -Q works fine. If I mv ~/.config/emacs{,.bak} I see the
problem. I don't have a /etc/emacs folder either, so maybe that helps
you in reproducing the issue?

Eli Zaretskii wrote:
>   . emacs -Q -nw
>   . in *scratch* type "features" (without the quotes)
>   . go to the end of "features", after the final 's', and type C-j
>   . if the list Emacs inserts into the buffer has ellipsis in it, go
>     to that ellipsis and type RET
>   . post the resulting list here

This feature didn't do anything right after the start, but after closing
the *scratch* window, and then trying again in the new *scratch* I got:

features
(comp-cstr warnings rx cl-seq cl-macs cl-extra help-mode tool-bar seq gv subr-x byte-opt cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl tooltip eldoc paren electr\
ic uniquify ediff-hook vc-hooks lisp-float-type elisp-mode tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch\
 easymenu timer select mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-v\
iet 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 simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env co\
de-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind kqueue lcms2 multi-tty make-network-process native-compile emacs)


> I think at this point only running under a debugger will help us
> efficiently.  So please act according to the instructions below, and
> show the backtrace it produces:
> 
>   $ cd /path/to/emacs/src/
>   $ gdb ./emacs
>   GNU gdb (GDB) 11.1
>   Copyright (C) 2021 Free Software Foundation, Inc.
>   ...
>   (gdb) source ./.gdbinit
>   (gdb) break Fsignal
>   (gdb) commands
>   Type commands for breakpoint(s) 2, one per line.
>   End with a line saying just "end".
>   > pp error_symbol
>   > pp data
>   > end
>   (gdb) run -Q -nw
> 
> When the breakpoint breaks, look at the error_symbol and data printed
> by GDB; if the symbol are not "void-function", type "continue" at
> GDB's prompt to run Emacs further.  When you eventually get symbol as
> "void-function" and data that mentions regexp-opt-group, type:
> 
>   (gdb) thread apply all bt
> 
> This should produce both C-level backtrace and Lisp-level backtrace of
> all the threads in Emacs.  Please post that here in its entirety.

 /usr/pkgmk/work/emacs/src/emacs/src % egdb ./emacs
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = screen-256color
Breakpoint 1 at 0x137c7f
.gdbinit:1239: Error in sourced command file:
No symbol "defined_HAVE_X_WINDOWS" in current context.
[snip: other instructions]
And after

    (gdb) run -Q -nw

I get: 

    Breakpoint 3, 0x00000d95326ee646 in Fsignal ()
    No symbol "error_symbol" in current context.

Also after each consecutive continue, until emacs starts normally,
without triggering the error.

So I think something is missing here. But what?




# Han

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>, Andrea Corallo <akrl <at> sdf.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Sat, 20 Nov 2021 11:36:16 +0200

> Date: Fri, 19 Nov 2021 23:18:04 +0100
> From: Han Boetes <han <at> boetes.org>
> Cc: 51689 <at> debbugs.gnu.org
> 
> Another thing I noticed: if there is a valid ~/.config/emacs/init.el,
> emacs -nw -Q works fine. If I mv ~/.config/emacs{,.bak} I see the
> problem. I don't have a /etc/emacs folder either, so maybe that helps
> you in reproducing the issue?

Not really: too many unknowns here.

> And after
> 
>     (gdb) run -Q -nw
> 
> I get: 
> 
>     Breakpoint 3, 0x00000d95326ee646 in Fsignal ()
>     No symbol "error_symbol" in current context.

Your build lacks debugging symbols, sigh.

Anyway. I think I'm beginning to understand what's going on here.

Andrea, I need your help here.

Here's what I think happens: At startup, we call
tramp-register-archive-file-name-handler, because tramp-archive.el
does this:

  ;;;###autoload
  (progn (defun tramp-register-archive-file-name-handler ()
    "Add archive file name handler to `file-name-handler-alist'."
    (when tramp-archive-enabled
      (add-to-list 'file-name-handler-alist
		   (cons (tramp-archive-autoload-file-name-regexp)
			 #'tramp-archive-autoload-file-name-handler))
      (put #'tramp-archive-autoload-file-name-handler 'safe-magic t))))

  ;;;###autoload
  (progn
    (add-hook 'after-init-hook #'tramp-register-archive-file-name-handler)
    (add-hook
     'tramp-archive-unload-hook
     (lambda ()
       (remove-hook
	'after-init-hook #'tramp-register-archive-file-name-handler))))

So we call tramp-register-archive-file-name-handler, which invokes
tramp-archive-autoload-file-name-regexp, which does:

  ;; The definition of `tramp-archive-file-name-regexp' contains calls
  ;; to `regexp-opt', which cannot be autoloaded while loading
  ;; loaddefs.el.  So we use a macro, which is evaluated only when needed.
  ;;;###autoload
  (progn (defmacro tramp-archive-autoload-file-name-regexp ()
    "Regular expression matching archive file names."
    '(concat
      "\\`" "\\(" ".+" "\\."
	;; Default suffixes ...
	(regexp-opt tramp-archive-suffixes)
	;; ... with compression.
	"\\(?:" "\\." (regexp-opt tramp-archive-compression-suffixes) "\\)*"
      "\\)" ;; \1
      "\\(" "/" ".*" "\\)" "\\'"))) ;; \2

So this calls regexp-opt, which is an autoloaded function, so it loads
regexp-opt.  regexp-opt is preloaded (in GUI-capable builds), so we
should have regexp-opt.eln under native-lisp/ directory, but it is not
actually preloaded in --without-x builds.  And regexp-opt (the
function) calls regexp-opt-group.  So it sounds like when
regexp-opt.eln is auto-loaded on Han's platform, it signals this
error, for some reason, although regexp-opt-group is defined inside
regexp-opt.el.  Some bug in libgccjit on OpenBSD, perhaps, or in GCC
11 on that OS?  Or something else, perhaps because regexp-opt.eln is
in preloaded/, but not actually preloaded into --without-x builds?

Andrea, how to continue investigating this?  This bug is currently the
only blocker that prevents us from going to the first pretest of Emacs
28, so it's quite frustrating that we cannot solve it for the past 12
days.  If we cannot resolve this quickly, I'm tempted to ignore this
problem as something specific to OpenBSD, since my own build
"--without-x" (on GNU/Linux) doesn't have this problem.

Thanks.

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

From: Han Boetes <han <at> boetes.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Sat, 20 Nov 2021 15:59:32 +0100

Eli Zaretskii wrote:
> I think at this point only running under a debugger will help us
> efficiently.  So please act according to the instructions below, and
> show the backtrace it produces:
> 
>   $ cd /path/to/emacs/src/
>   $ gdb ./emacs
>   GNU gdb (GDB) 11.1
>   Copyright (C) 2021 Free Software Foundation, Inc.
>   ...
>   (gdb) source ./.gdbinit
>   (gdb) break Fsignal
>   (gdb) commands
>   Type commands for breakpoint(s) 2, one per line.
>   End with a line saying just "end".
>   > pp error_symbol
>   > pp data
>   > end
>   (gdb) run -Q -nw
> 
> When the breakpoint breaks, look at the error_symbol and data printed
> by GDB; if the symbol are not "void-function", type "continue" at
> GDB's prompt to run Emacs further.  When you eventually get symbol as
> "void-function" and data that mentions regexp-opt-group, type:
> 
>   (gdb) thread apply all bt
> 
> This should produce both C-level backtrace and Lisp-level backtrace of
> all the threads in Emacs.  Please post that here in its entirety.

Ah! Symbols! How could I forget! There we go!

Thread 1 (thread 539720):
#0  Fsignal (error_symbol=XIL(0xe100), data=XIL(0x9c8f1ef8c23)) at eval.c:1790
#1  0x000009c69f24c271 in xsignal (error_symbol=XIL(0xe100), data=XIL(0x9c8f1ef8c23)) at lisp.h:4155
#2  0x000009c69f252211 in xsignal1 (error_symbol=XIL(0xe100), arg=XIL(0x2b1578948)) at eval.c:1949
#3  0x000009c69f22d539 in Fdefault_value (symbol=XIL(0x2b1578948)) at data.c:1824
#4  0x000009c69f24e5a1 in Fdefault_toplevel_value (symbol=XIL(0x2b1578948)) at eval.c:755
#5  0x000009c69f25633a in funcall_subr (subr=0x9c69f72ca00 <Sdefault_toplevel_value>, numargs=1, args=0x7f7ffffe9568) at eval.c:3143
#6  0x000009c69f255d66 in Ffuncall (nargs=2, args=0x7f7ffffe9560) at eval.c:3068
#7  0x000009c8cd6fcc36 in F637573746f6d2d696e697469616c697a652d7265736574_custom_initialize_reset_0 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/custom-e63dc4f2-1b2226d6.eln
#8  0x000009c69f25635e in funcall_subr (subr=0x9c95095fc00, numargs=2, args=0x7f7ffffe9738) at eval.c:3145
#9  0x000009c69f255d66 in Ffuncall (nargs=3, args=0x7f7ffffe9730) at eval.c:3068
#10 0x000009c8cd6fd492 in F637573746f6d2d6465636c6172652d7661726961626c65_custom_declare_variable_0 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/custom-e63dc4f2-1b2226d6.eln
#11 0x000009c69f256207 in funcall_subr (subr=0x9c95092cf30, numargs=7, args=0x7f7ffffe9940) at eval.c:3123
#12 0x000009c69f255d66 in Ffuncall (nargs=8, args=0x7f7ffffe9938) at eval.c:3068
#13 0x000009c69f2b6fb4 in exec_byte_code (bytestr=XIL(0x9c93e356a44), vector=XIL(0x9c93135b2a5), maxdepth=make_fixnum(8), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:632
#14 0x000009c69f2b60a5 in Fbyte_code (bytestr=XIL(0x9c93e356a44), vector=XIL(0x9c93135b2a5), maxdepth=make_fixnum(8)) at bytecode.c:334
#15 0x000009c69f25436e in eval_sub (form=XIL(0x9c8e1175223)) at eval.c:2549
#16 0x000009c69f2536cc in Feval (form=XIL(0x9c8e1175223), lexical=XIL(0x30)) at eval.c:2372
#17 0x000009c91457a821 in top_level_run () from /usr/obj/work/emacs/src/emacs/native-lisp/29.0.50-8f1f8882/bytecomp-4f134b45-abb2ff90.eln
#18 0x000009c69f2c8c2c in load_comp_unit (comp_u=0x9c931340908, loading_dump=false, late_load=false) at comp.c:5093
#19 0x000009c69f2c9bad in Fnative_elisp_load (filename=XIL(0x9c93133c8c4), late_load=XIL(0)) at comp.c:5309
#20 0x000009c69f297527 in Fload (file=XIL(0x9c950d0fdac), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1564
#21 0x000009c69f2978b3 in save_match_data_load (file=XIL(0x9c950d0fdac), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1628
#22 0x000009c69f269c2f in Frequire (feature=XIL(0x2b1558dd8), filename=XIL(0), noerror=XIL(0)) at fns.c:3188
#23 0x000009c69f25638d in funcall_subr (subr=0x9c69f72f940 <Srequire>, numargs=1, args=0x7f7ffffea3f0) at eval.c:3148
#24 0x000009c69f255d66 in Ffuncall (nargs=2, args=0x7f7ffffea3e8) at eval.c:3068
#25 0x000009c69f2b6fb4 in exec_byte_code (bytestr=XIL(0x9c8e35bf664), vector=XIL(0x9c8ac9a3755), maxdepth=make_fixnum(10), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:632
#26 0x000009c69f2b60a5 in Fbyte_code (bytestr=XIL(0x9c8e35bf664), vector=XIL(0x9c8ac9a3755), maxdepth=make_fixnum(10)) at bytecode.c:334
#27 0x000009c69f25436e in eval_sub (form=XIL(0x9c90d9e8293)) at eval.c:2549
#28 0x000009c69f2536cc in Feval (form=XIL(0x9c90d9e8293), lexical=XIL(0x30)) at eval.c:2372
#29 0x000009c8daf2a7f2 in top_level_run () from /usr/obj/work/emacs/src/emacs/native-lisp/29.0.50-8f1f8882/comp-af992f0e-a040a5e7.eln
#30 0x000009c69f2c8c2c in load_comp_unit (comp_u=0x9c8ac9bd328, loading_dump=false, late_load=false) at comp.c:5093
#31 0x000009c69f2c9bad in Fnative_elisp_load (filename=XIL(0x9c93e37cca4), late_load=XIL(0)) at comp.c:5309
#32 0x000009c69f297527 in Fload (file=XIL(0x9c9509a82e4), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1564
#33 0x000009c69f2978b3 in save_match_data_load (file=XIL(0x9c9509a82e4), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1628
#34 0x000009c69f269c2f in Frequire (feature=XIL(0x3cc0), filename=XIL(0), noerror=XIL(0)) at fns.c:3188
#35 0x000009c69f2c80d3 in maybe_defer_native_compilation (function_name=XIL(0x29ebd14f0), definition=XIL(0x9c8ac9b58ed)) at comp.c:4870
#36 0x000009c69f22a71e in Fdefalias (symbol=XIL(0x29ebd14f0), definition=XIL(0x9c8ac9b58ed), docstring=XIL(0)) at data.c:830
#37 0x000009c69f25436e in eval_sub (form=XIL(0x9c8d0c35ce3)) at eval.c:2549
#38 0x000009c69f29a0c2 in readevalloop (readcharfun=XIL(0x6990), infile0=0x7f7ffffeb2f0, sourcename=XIL(0x9c93e36f6a4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2325
#39 0x000009c69f2975ec in Fload (file=XIL(0x9c93e36f444), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1578
#40 0x000009c69f2978b3 in save_match_data_load (file=XIL(0x9c93e36f444), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1628
#41 0x000009c69f269c2f in Frequire (feature=XIL(0x2d0b6d670), filename=XIL(0), noerror=XIL(0)) at fns.c:3188
#42 0x000009c69f25638d in funcall_subr (subr=0x9c69f72f940 <Srequire>, numargs=1, args=0x7f7ffffeb540) at eval.c:3148
#43 0x000009c69f255d66 in Ffuncall (nargs=2, args=0x7f7ffffeb538) at eval.c:3068
#44 0x000009c69f2b6fb4 in exec_byte_code (bytestr=XIL(0x9c93e36f404), vector=XIL(0x9c8ac9c3ab5), maxdepth=make_fixnum(10), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:632
#45 0x000009c69f2b60a5 in Fbyte_code (bytestr=XIL(0x9c93e36f404), vector=XIL(0x9c8ac9c3ab5), maxdepth=make_fixnum(10)) at bytecode.c:334
#46 0x000009c69f25436e in eval_sub (form=XIL(0x9c8d0c36fc3)) at eval.c:2549
#47 0x000009c69f29a0c2 in readevalloop (readcharfun=XIL(0x6990), infile0=0x7f7ffffebc70, sourcename=XIL(0x9c93e384fa4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2325
#48 0x000009c69f2975ec in Fload (file=XIL(0x9c93e384dc4), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1578
#49 0x000009c94e6e8842 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_50 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/faces-e245131e-8647c9a2.eln
#50 0x000009c69f25633a in funcall_subr (subr=0x9c950dde6b0, numargs=1, args=0x7f7ffffebe58) at eval.c:3143
#51 0x000009c69f255d66 in Ffuncall (nargs=2, args=0x7f7ffffebe50) at eval.c:3068
#52 0x000009c94e6e8646 in F7474792d66696e642d74797065_tty_find_type_0 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/faces-e245131e-8647c9a2.eln
#53 0x000009c69f25635e in funcall_subr (subr=0x9c9509c3ca0, numargs=2, args=0x7f7ffffec038) at eval.c:3145
#54 0x000009c69f255d66 in Ffuncall (nargs=3, args=0x7f7ffffec030) at eval.c:3068
#55 0x000009c94e6e8a70 in F7474792d72756e2d7465726d696e616c2d696e697469616c697a6174696f6e_tty_run_terminal_initialization_0 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/faces-e245131e-8647c9a2.eln
#56 0x000009c69f25638d in funcall_subr (subr=0x9c950c44d50, numargs=3, args=0x7f7ffffec1e8) at eval.c:3148
#57 0x000009c69f255d66 in Ffuncall (nargs=4, args=0x7f7ffffec1e0) at eval.c:3068
#58 0x000009c986a3ad0d in F636f6d6d616e642d6c696e65_command_line_0 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/startup-a18662e4-026a11a7.eln
#59 0x000009c69f256321 in funcall_subr (subr=0x9c950c21030, numargs=0, args=0x7f7ffffec3c0) at eval.c:3141
#60 0x000009c69f255d66 in Ffuncall (nargs=1, args=0x7f7ffffec3b8) at eval.c:3068
#61 0x000009c986a363a6 in F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 () from /usr/obj/work/emacs/src/emacs/src/../native-lisp/29.0.50-8f1f8882/preloaded/startup-a18662e4-026a11a7.eln
#62 0x000009c69f2542e3 in eval_sub (form=XIL(0x9c950d57a43)) at eval.c:2540
#63 0x000009c69f2536cc in Feval (form=XIL(0x9c950d57a43), lexical=XIL(0)) at eval.c:2372
#64 0x000009c69f166219 in top_level_2 () at keyboard.c:1143
#65 0x000009c69f2510cc in internal_condition_case (bfun=0x9c69f1661ef <top_level_2>, handlers=XIL(0x90), hfun=0x9c69f165948 <cmd_error>) at eval.c:1495
#66 0x000009c69f166271 in top_level_1 (ignore=XIL(0)) at keyboard.c:1151
#67 0x000009c69f2501a9 in internal_catch (tag=XIL(0xd110), func=0x9c69f16621b <top_level_1>, arg=XIL(0)) at eval.c:1226
#68 0x000009c69f16612b in command_loop () at keyboard.c:1111
#69 0x000009c69f1653c9 in recursive_edit_1 () at keyboard.c:721
#70 0x000009c69f165604 in Frecursive_edit () at keyboard.c:804
#71 0x000009c69f160ff3 in main (argc=3, argv=0x7f7ffffec838) at emacs.c:2345

Lisp Backtrace:
"default-toplevel-value" (0xfffe9568)
"custom-initialize-reset" (0xfffe9738)
"custom-declare-variable" (0xfffe9940)
"byte-code" (0xfffe9db0)
"require" (0xfffea3f0)
"byte-code" (0xfffea9b0)
"defalias" (0xfffeb030)
"require" (0xfffeb540)
"byte-code" (0xfffeb9b0)
0x50dde6b0 PVEC_SUBR
"tty-find-type" (0xfffec038)
"tty-run-terminal-initialization" (0xfffec1e8)
"command-line" (0xfffec3c0)
"normal-top-level" (0xfffec4d0)

Breakpoint 3, Fsignal (error_symbol=XIL(0xe100), data=XIL(0x9c9423a4e03)) at eval.c:1790
1790      if (NILP (error_symbol) && NILP (data))
void-variable
(byte-compile-verbose)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689 <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Sat, 20 Nov 2021 17:15:12 +0200

> Date: Sat, 20 Nov 2021 15:59:32 +0100
> From: Han Boetes <han <at> boetes.org>
> Cc: 51689 <at> debbugs.gnu.org
> 
> Breakpoint 3, Fsignal (error_symbol=XIL(0xe100), data=XIL(0x9c9423a4e03)) at eval.c:1790
> 1790      if (NILP (error_symbol) && NILP (data))
> void-variable
> (byte-compile-verbose)

This is OK, but this is not the call to 'signal' that we are looking
for.  As I said in my instructions:

> > When the breakpoint breaks, look at the error_symbol and data printed
> > by GDB; if the symbol are not "void-function", type "continue" at
> > GDB's prompt to run Emacs further.  When you eventually get symbol as
> > "void-function" and data that mentions regexp-opt-group, type:
> > 
> >   (gdb) thread apply all bt

In the above you have void-variable as error_symbol and the data does
not mention regexp-opt-group.  So you need to type "continue" until
you hit this breakpoint with the correct conditions, and then produce
the backtrace.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <han <at> boetes.org>
Cc: 51689-done <at> debbugs.gnu.org
Subject: Re: bug#51689: emacs
Date: Sun, 21 Nov 2021 08:31:29 +0200

> Date: Sat, 20 Nov 2021 22:05:55 +0100
> From: Han Boetes <han <at> boetes.org>
> 
> > > > When the breakpoint breaks, look at the error_symbol and data printed
> > > > by GDB; if the symbol are not "void-function", type "continue" at
> > > > GDB's prompt to run Emacs further.  When you eventually get symbol as
> > > > "void-function" and data that mentions regexp-opt-group, type:
> > > > 
> > > >   (gdb) thread apply all bt
> > 
> > In the above you have void-variable as error_symbol and the data does
> > not mention regexp-opt-group.  So you need to type "continue" until
> > you hit this breakpoint with the correct conditions, and then produce
> > the backtrace.
> 
> And when I finally understood all the details of how to create the
> backtrace and building emacs with symbols again, which takes over 6
> hours, I noticed gdb ran out of memory and that I could no longer
> reproduce the problem with the latest code from git.

Thanks, 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.