GNU bug report logs - #17893
24.4.50; (error "Marker does not point anywhere")

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Tue, 1 Jul 2014 21:12:01 UTC

Severity: normal

Found in version 24.4.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 17893 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: bug#17893: 24.4.50; (error "Marker does not point anywhere")
Date: Mon, 20 Nov 2017 17:45:43 +0200
> Date: Sun, 19 Nov 2017 20:31:06 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> Cc: 17893 <at> 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).




This bug report was last modified 7 years and 179 days ago.

Previous Next


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