From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: gerd.moellmann@t-online.de (Gerd Moellmann) Newsgroups: gmane.emacs.devel Subject: Re: Mysterious redisplay problem and a trap in xdisp.c Date: 09 Feb 2002 23:42:15 +0100 Message-ID: <86aduigtvc.fsf@gerd.dnsq.org> References: <5xadui5q2j.fsf@kfs2.cua.dk> Reply-To: gerd@gnu.org NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1013295282 2147 195.204.10.66 (9 Feb 2002 22:54:42 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 9 Feb 2002 22:54:42 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 16ZgOH-0000YX-00 for ; Sat, 09 Feb 2002 23:54:41 +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 16ZgF1-0001hU-00; Sat, 09 Feb 2002 17:45:07 -0500 Original-Received: from mailout01.sul.t-online.com ([194.25.134.80]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16ZgCP-0001dm-00 for ; Sat, 09 Feb 2002 17:42:25 -0500 Original-Received: from fwd01.sul.t-online.de by mailout01.sul.t-online.com with smtp id 16ZgCK-0007Du-00; Sat, 09 Feb 2002 23:42:20 +0100 Original-Received: from gerd.dnsq.org (520015515780-0001@[217.230.100.24]) by fwd01.sul.t-online.com with esmtp id 16ZgCH-0HsjC4C; Sat, 9 Feb 2002 23:42:17 +0100 Original-Received: (from gerd@localhost) by gerd.dnsq.org (8.11.6/8.11.4) id g19MgGQ02532; Sat, 9 Feb 2002 23:42:16 +0100 (CET) (envelope-from gerd@gnu.org) X-Authentication-Warning: gerd.dnsq.org: gerd set sender to gerd@gnu.org using -f Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: <5xadui5q2j.fsf@kfs2.cua.dk> Original-Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 X-Sender: 520015515780-0001@t-dialin.net 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:931 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:931 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. >From the top of my head, I'm not aware of code in redisplay using pointers into buffers instead of buffer char/byte positions, i.e., int offsets from the buffer start. So, I guess the only way to find out if that is the problem, and if so where it is, is to look at the stack backtraces when stopping in the debugger in make_gap_smaller during redisplay and to check all the relevant functions from the backtrace if they somehow keep a pointer into a buffer around the call to something that can GC. (A quick fix would be to disable the shrinking of the gap for GCs during redisplay, which could be done by checking the value of the variable redisplaying_p.) _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel