GNU bug report logs - #36431
Crash in marker.c:337

Previous Next

Package: emacs;

Reported by: Werner LEMBERG <wl <at> gnu.org>

Date: Sat, 29 Jun 2019 11:19:01 UTC

Severity: normal

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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: wl <at> gnu.org, 36431 <at> debbugs.gnu.org
Subject: bug#36431: Crash in marker.c:337
Date: Sun, 30 Jun 2019 17:39:49 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: wl <at> gnu.org,  36431 <at> debbugs.gnu.org
> Date: Sat, 29 Jun 2019 18:56:53 -0400
> 
> I don't really know how to reproduce your bug, but I think I have an
> idea of what might be going on.
> Can you try the patch below, to see if it fixes your problem?

AFAICT, this patch moves the call to move_gap_both from a fragment
where we must decode the inserted text to a fragment where such a
decoding might not be necessary.  If I'm right, then this makes
insert-file-contents slower in some cases, because moving the gap
might be very expensive with large buffers.

More generally, I'd be leery to make significant changes ion
insert-file-contents just to placate that single assertion.  What do
we gain with that assertion except some theoretical correctness?
OTOH, the losses, in stability, performance, and not least our time
and energy is (or at least might be) real and tangible.  So why
bother?




This bug report was last modified 5 years and 312 days ago.

Previous Next


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