bug#69459: 30.0.50; temacs, SEGV while pdumping

bug#69459: 30.0.50; temacs, SEGV while pdumping

[Gerd Möllmann]

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.

bug#69459: 30.0.50; temacs, SEGV while pdumping

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@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.