all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: eassert always aborts in eval.c in an optimized build
Date: Sun, 27 Oct 2024 21:26:46 +0200	[thread overview]
Message-ID: <865xpd8hzd.fsf@gnu.org> (raw)
In-Reply-To: <aa4f0ef5-09ea-4ec7-8d91-3fb66da91082@cs.ucla.edu> (message from Paul Eggert on Sun, 27 Oct 2024 10:57:21 -0700)

> Date: Sun, 27 Oct 2024 10:57:21 -0700
> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-10-27 01:50, Eli Zaretskii wrote:
> > Something is wrong with our definition/use of eassert in eval.c when
> > Emacs is compiled with optimizations and with --enable-checking: all
> > the functions in eval.c that assert pdl->kind's value are compiled
> > into code that always aborts.
> 
> A quick look suggests that although the actual code is fine, GDB is 
> confused and its "disassemble" and other commands think that the symbol 
> "backtrace_function" stands for the address of just part of the 
> backtrace_function code, not the address of the function's first 
> instruction.

But then why does xbacktrace always abort?  Are you saying it calls
the part that aborts?

> If my guess is right, if you try to debug Emacs with GDB and use 
> xbacktrace or similar commands, things will go haywire. You'll see 
> symptoms like this:
> 
> (gdb) p backtrace_function
> $1 = {Lisp_Object (union specbinding *)} 0x6ed5c <backtrace_function>
> 
> ... whereas the shell command "nm emacs | grep backtrace_function" 
> outputs this:
> 
> 0000000000293cd0 T backtrace_function
> 000000000006ee78 t backtrace_function.cold
> 000000000006ed5c t backtrace_function.part.0

I see the first and the last of these 3 lines; mo "cold" part.

> ... and we can see that GDB has the wrong "backtrace_function".
> 
> Does this match the symptoms you're observing?

Sounds like that, yes.

> If my guess is right, GDB should be fixed, and also we should look into 
> patching Emacs to work around the GDB bug.

I see this with GDB 12.1 on GNU/Linux and with GDB 15.1 on MS-Windows,
so I'm guessing fixing GDB will not be easy, and there will be many
un-fixed GDB versions around even after GDB is fixed.  We should work
around this in Emacs regardless.

Thanks.



  reply	other threads:[~2024-10-27 19:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-27  8:50 eassert always aborts in eval.c in an optimized build Eli Zaretskii
2024-10-27 17:57 ` Paul Eggert
2024-10-27 19:26   ` Eli Zaretskii [this message]
2024-10-27 19:30     ` Paul Eggert
2024-10-28  0:34   ` Paul Eggert
2024-10-28 13:49     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=865xpd8hzd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.