bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57751: 29.0.50; crash in GC


From: Gerd Möllmann
Subject: bug#57751: 29.0.50; crash in GC
Date: Tue, 13 Sep 2022 07:20:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin)

Hi Sam,

Sam Steingold <sds@gnu.org> writes:

> About a week ago Emacs crashed and now it consistently crashes on
> startup if I agree to load the desktop file from the crashed session.
> If I refuse to load the desktop file and instead load files on-by-one, I
> also eventually (an hour or a day later) get a crash, albeit I do get
> some work done in the meantime.
> I did a few `git pull && make bootstrap` (the latest this morning) in
> the vain (so far) hope that the problem disappears.

Ok.

> (lldb) run
> Process 73681 launched: '/Users/sdsg/src/emacs/build/src/emacs' (x86_64)
> 2022-09-12 10:08:57.646156-0400 emacs[73681:5354078] SecTaskLoadEntitlements 
> failed error=22 cs_flags=20, pid=73681
> 2022-09-12 10:08:57.646250-0400 emacs[73681:5354078]
> SecTaskCopyDebugDescription: emacs[73681]/0#-1 LF=0

These messages are a bit strange, I've never seen them in my system.
But since they don't seem to affect LLDB, I guess we can ignore them.

> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=EXC_I386_GPFLT)
>     frame #0: 0x0000000100154d30 emacs`process_mark_stack(base_sp=0) at 
> alloc.c:7013:14 [opt]
>    7010              "cold" and do not have mark bits.  */
>    7011           if (pdumper_object_p (XFLOAT (obj)))
>    7012             eassert (pdumper_cold_object_p (XFLOAT (obj)));
> -> 7013           else if (!XFLOAT_MARKED_P (XFLOAT (obj)))
>    7014             XFLOAT_MARK (XFLOAT (obj));
>    7015           break;
>    7016
> Target 0: (emacs) stopped.

Looks like a heap corruption to me, which is detected during a GC that
is done while autoloading something.

> the "good" part is that, apparently, I can reproduce the crash on
> demand.

Ok.  How boring ;-)

> Please tell me if there anything else I can do.

I'd start by running an Emacs with address sanitizer enabled.  If that
doesn't show something, I guess we have to git bisect to find the
culprit.  But I recommend trying with ASAN first, that has proven itself
very useful in the past.

I've written me a zsh shell script for that and other purposes which I
attach.  The important command line option of that script is --asan
which configures Emacs with the right CFLAGS and LDFLAGS.  There are a
number of other command line options you might find useful, please see
the script, or invoke it with --help.

(If you use it for building Emacs, you'll need to "brew install bear",
or remove the call to bear in the script.  Also, you might want to use
--elc if you don't use native compilatin.)

In our case you would just do

  make-emacs --asan

somewhere in your Git worktree.  That builds a clean Emacs in-tree with
ASAN enabled.  Caution: it does a git clean -xdf by default.

You then run that Emacs in LLDB

  cd src
  lldb emacs

Please start Emacs from src because LLDB then picks up the (limited)
LLDB support for debugging Emacs that we have in etc/emacs_lldb.py.

When ASAN finds a problem, it stops the debugger, and we can look
around.

Attachment: make-emacs
Description: make-emacs


reply via email to

[Prev in Thread] Current Thread [Next in Thread]