From: gerd.moellmann@t-online.de (Gerd Moellmann)
Cc: emacs-devel@gnu.org
Subject: Re: Mysterious redisplay problem and a trap in xdisp.c
Date: 09 Feb 2002 23:42:15 +0100 [thread overview]
Message-ID: <86aduigtvc.fsf@gerd.dnsq.org> (raw)
In-Reply-To: <5xadui5q2j.fsf@kfs2.cua.dk>
storm@cua.dk (Kim F. Storm) writes:
[...]
> I have now tracked the problem down to the following change:
>
> 2001-12-11 Andrew Innes <andrewi@gnu.org>
>
> * 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
next prev parent reply other threads:[~2002-02-09 22:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-09 20:59 Mysterious redisplay problem and a trap in xdisp.c Kim F. Storm
2002-02-09 22:42 ` Gerd Moellmann [this message]
2002-02-09 23:06 ` Kim F. Storm
2002-02-11 2:09 ` Richard Stallman
2002-02-11 8:27 ` Kim F. Storm
-- strict thread matches above, loose matches on Subject: below --
2002-02-07 12:59 Kim F. Storm
2002-02-07 19:47 ` Eli Zaretskii
2002-02-08 13:57 ` Richard Stallman
2002-02-08 20:50 ` Kim F. Storm
2002-02-09 7:25 ` Eli Zaretskii
2002-02-10 5:17 ` Richard Stallman
2002-02-11 2:09 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86aduigtvc.fsf@gerd.dnsq.org \
--to=gerd.moellmann@t-online.de \
--cc=emacs-devel@gnu.org \
--cc=gerd@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).