bug#17893: 24.4.50; (error "Marker does not point anywhere")

[Eli Zaretskii]

> Date: Sun, 19 Nov 2017 20:31:06 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> Cc: 17893@debbugs.gnu.org
> 
> > Yup, sounds like we have a bug in clone-buffer, at least.
> > 
> > 
> >         Stefan
> 
> Right-o, here's a fix with respect to the emacs-26 branch:
> 
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 7d47d0f..64b7bde 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8518,6 +8518,15 @@ clone-buffer
>               (error nil)))
>           lvars)
>  
> +      ;; Update markers in the copied mark ring to refer to the new buffer.
> +      (setq mark-ring
> +            (mapcar (lambda (m)
> +                      (let ((new-marker))
> +                        (setq new-marker (copy-marker m))
> +                        (move-marker new-marker new-marker (current-buffer))
> +                        new-marker))
> +                    mark-ring))
> +
>        ;; Run any hooks (typically set up by the major mode
>        ;; for cloning to work properly).
>        (run-hooks 'clone-buffer-hook))
> 
> It fixes the minimal recipe to reproduce this bug:

Bother: this is actually the tip of an iceberg.  Buffer local
variables that get cloned by clone-buffer could hold any number of
markers pointing into the original buffer.  E.g., info.el itself
maintains a per-buffer marker in Info-tag-table-marker; evaluate it
after M-n and see what it tells you.

For mark-ring, I think it's easier to just reset it to nil in the new
clone (it's arguably even more correct, since this is a fresh buffer),
but in general this is a ticking bomb, unless I'm missing something.
If I'm right, the only solution is to walk all the markers that point
to the parent buffer and clone them to point to the cloned buffer
(this has to be done in C).