On Thu, Mar 12, 2020 at 6:13 PM Pieter van Oostrum
<pieter-l@vanoostrum.org> wrote:
> > My guess is 0x7ffeef270000 is your stack's guard page... Can you print
> > $rsp to confirm?
>
> Sorry, because of the erratic behaviour of GDB I killed that one. I have a new segfault in the GC. It is a long stack trace, so it could be a stack overflow. And, by the way, I had the two brakpoints set for the assignments to marker->charpos that Eli suggested, but they were not triggered. I have dumped a part of the stack trace below.

Thanks! I believe that solves it.

That indeed looks like a stack overflow.

Here's some speculation about what I think is happening:

We're seeing deep recursion in the garbage collector. If you look at
the tag bits of the objects marked by mark_object, you'll notice the
sequence is

symbol - cons - vectorlike - vectorlike - symbol - cons - vectorlike -
vectorlike - ...

That means there are thousands of symbols referring to values which
again contain symbols, and so on.

I suspect this code in vm-summary.el, or similar code, at least:

(defun vm-make-message ()
  "Create a new blank message struct."
  (let ((mvec (make-vector 5 nil))
    sym)
    (vm-set-softdata-of mvec (make-vector vm-softdata-vector-length nil))
    (vm-set-location-data-of
     mvec (make-vector vm-location-data-vector-length nil))
    (vm-set-mirror-data-of
     mvec (make-vector vm-mirror-data-vector-length nil))
    (vm-set-message-id-number-of mvec (int-to-string vm-message-id-number))
    (vm-increment vm-message-id-number)
    (vm-set-buffer-of mvec (current-buffer))
    ;; We use an uninterned symbol here as a level of indirection
    ;; from a purely self-referential structure.  This is
    ;; necessary so that Emacs debugger can be used on this
    ;; program.
    (setq sym (make-symbol "<<>>"))
    (set sym mvec)
    (vm-set-real-message-sym-of mvec sym)
    (vm-set-mirrored-message-sym-of mvec sym)
    ;; Another uninterned symbol for the virtual messages list.
    (setq sym (make-symbol "<v>"))
    (set sym nil)
    (vm-set-virtual-messages-sym-of mvec sym)
    ;; Another uninterned symbol for the reverse link
    ;; into the message list.
    (setq sym (make-symbol "<--"))
    (vm-set-reverse-link-sym-of mvec sym)
    mvec ))

Essentially, that code is building a singly-linked list of message
vectors, but the links go via symbols rather than directly to the next
message. The garbage collector isn't written for that case, and
recurses rather than iterating, causing the stack overflow.

The first attachment to this message is an Elisp file which does the
same thing, by creating thousands of symbols. On GNU/Linux, with
fairly default standard stack size settings, I get a segfault after
some 85,000 symbols have been created.

The second attachment is a patch which is
1. untested
2. a dirty workaround
3. not intended for inclusion in the master branch
4. not intended for inclusion in the emacs-27 branch.

It's possible this patch will work around the problem and result in a
different bug, or, less optimistically, fix this bug. With the patch,
I'm able to make it through the first 2^20 iterations of
symbol-crash.el without a segfault.