From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Mysterious redisplay problem and a trap in xdisp.c Date: 10 Feb 2002 00:06:16 +0100 Message-ID: <5xzo2i45nb.fsf@kfs2.cua.dk> References: <5xadui5q2j.fsf@kfs2.cua.dk> <86aduigtvc.fsf@gerd.dnsq.org> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1013296551 3442 195.204.10.66 (9 Feb 2002 23:15:51 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 9 Feb 2002 23:15:51 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16Zgil-0000tQ-00 for ; Sun, 10 Feb 2002 00:15:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16ZgZM-0002Qc-00; Sat, 09 Feb 2002 18:06:08 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.33 #1 (Debian)) id 16ZgYK-0002Ih-00; Sat, 09 Feb 2002 18:05:04 -0500 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 82E307C035; Sat, 9 Feb 2002 23:05:02 +0000 (GMT) Original-To: gerd@gnu.org In-Reply-To: <86aduigtvc.fsf@gerd.dnsq.org> Original-Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:932 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:932 gerd.moellmann@t-online.de (Gerd Moellmann) writes: > storm@cua.dk (Kim F. Storm) writes: > > > [...] > > > I have now tracked the problem down to the following change: > > > > 2001-12-11 Andrew Innes > > > > * insdel.c (make_gap) [DOUG_LEA_MALLOC]: Call make_gap_smaller if > > arg is negative. > > > > If I comment out the call to make_gap_smaller in make_gap, the problem > > goes away! > > Hm, my theory, which might well be completely wrong, would be that a GC > during redisplay, via make_gap_smaller, changes the address of the > characters to be displayed, and that some code in redisplay doesn't > protect itself against that address change. I did some more digging, and discovered that make_gap_smaller does not preserves the value of BEG_UNCHANGED around the gap manipulation. In most cases, it will have moved that offset *ahead* in the buffer - i.e. redisplay does not look for buffer changes at the place where it actually happened... Why that results in inserting a newline I don't know - or whether it can explain the traps/aborts I've seen. In any case, I just committed a fix to restore BEG_UNCHANGED after the gap reduction, and it seems to have fixed the problem. -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel