GNU bug report logs - #69459
30.0.50; temacs, SEGV while pdumping

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 69459 in the body.
You can then email your comments to 69459 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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; temacs, SEGV while pdumping
Date: Wed, 28 Feb 2024 16:32:09 +0100

This is with my heavily modified local Emacs, which is based on master.
I think it applies to an unmodified master as well.

I got a SEGV in temacs while dumping a bootstrap.pdmp:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7fd9893b8a34)
    frame #0: 0x00000001002cb20c temacs`hash_table_index_size(h=0x00007fd9893b89f8) at lisp.h:2717:26
    frame #1: 0x00000001002cc4ad temacs`sweep_weak_table(h=0x00007fd9893b89f8, remove_entries_p=false) at fns.c:4980:17
    frame #2: 0x0000000100265c5d temacs`mark_and_sweep_weak_table_contents at alloc.c:6303:19
    frame #3: 0x000000010026502b temacs`garbage_collect at alloc.c:6554:3
    frame #4: 0x0000000100264b26 temacs`maybe_garbage_collect at alloc.c:6390:5
    frame #5: 0x00000001002b17ea temacs`maybe_gc at lisp.h:5870:5
    frame #6: 0x00000001002abd34 temacs`Ffuncall(nargs=3, args=(struct Lisp_Symbol *) $158 = 0x00007ff8c0a9f000) at eval.c:3073:3
    frame #7: 0x00000001002d4388 temacs`inorder(predicate=(struct Lisp_Subr *) $165 = 0x0000000100b51348, a=(struct Lisp_Subr *) $171 = 0x0000000100b4d3a0, b=(struct Lisp_Subr *) $177 = 0x0000000100b55520) at sort.c:116:11
    frame #8: 0x00000001002d3987 temacs`count_run(ms=0x00007ff7bfefb9f0, lo=(struct Lisp_Symbol *) $187 = 0x00007fd9895f74e8, hi=(struct Lisp_Symbol *) $198 = 0x00007fd9895fd298, descending=0x00007ff7bfefb9d7) at sort.c:180:7
    frame #9: 0x00000001002d308e temacs`tim_sort(predicate=(struct Lisp_Subr *) $205 = 0x0000000100b51348, seq=(struct Lisp_Symbol *) $215 = 0x00007fd9895f74e0, length=2999) at sort.c:943:19
    frame #10: 0x00000001002c4070 temacs`sort_list(list=(struct Lisp_Cons *) $222 = 0x00000001763e9a60, predicate=(struct Lisp_Symbol *) $240 = 0x0000000100ba97d0) at fns.c:2362:7
    frame #11: 0x00000001002c3e74 temacs`Fsort(seq=(struct Lisp_Cons *) $249 = 0x00000001763e9a60, predicate=(struct Lisp_Symbol *) $267 = 0x0000000100ba97d0) at fns.c:2399:11
    frame #12: 0x000000010026f7c6 temacs`dump_sort_copied_objects(ctx=0x00007ff7bfefca78) at pdumper.c:3325:5
  * frame #13: 0x000000010026e1df temacs`Fdump_emacs_portable(filename=(struct Lisp_String *) $276 = 0x00007fd88d0326e0, track_referrers=(struct Lisp_Symbol *) $294 = 0x0000000100ba36e0) at pdumper.c:4249:3

As one can see, a GC can run while dumping.

Fdump_emacs_portable uses a struct dump_context ctx_buf, which is
allocated on the stack (the local variable ctx is a pointer to the local
variable ctx_buf).

1. While dumping, pdump creates new Lisp_Objects (hash-tables, conses, ...)
that are stored in dump_context or subobjects of it, hash-tables for
example.

2. I can't find a function that marks a struct dump_context for GC. If
I'm right, nothing protects the objects that pdump creates from GC. 

As a fix I propose to inhibit GC while pdumping. Would be nice if
someone could check if (2) is right.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 69459 <at> debbugs.gnu.org
Subject: Re: bug#69459: 30.0.50; temacs, SEGV while pdumping
Date: Thu, 29 Feb 2024 05:21:40 +0100

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

> 1. While dumping, pdump creates new Lisp_Objects (hash-tables, conses, ...)
> that are stored in dump_context or subobjects of it, hash-tables for
> example.
>
> 2. I can't find a function that marks a struct dump_context for GC. If
> I'm right, nothing protects the objects that pdump creates from GC. 
>
> As a fix I propose to inhibit GC while pdumping. Would be nice if
> someone could check if (2) is right.

(2) is false: because ctx_buf is on the stack, stack scanning makes it
an ambiguous root.

So I'm closing this, because I haven't seen something like this SEGV in
an unmpdified Emacs.

Previous Next

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