[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overlays as an AA-tree

From: Joakim Jalap
Subject: Re: Overlays as an AA-tree
Date: Tue, 27 Sep 2016 08:26:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Store the position in the root and then an offset from the parent in
>> every child node?
> Something like that, I guess, yes.

That actually sounds quite neat.

>> But doing it like I do it now (updating all the char-positions after the
>> modification) shouldn't be slower than updating the positions of all
>> markers, right?
> Indeed, it's no worse than what we have, but it reduces the algorithmic
> benefit of the change.  IOW we can keep this for later.

For later it is :)

I followed Eli's advice and tried to more or less rip out all the code
which deals with overlays in xdisp.c etc, so that all functions that try
to gather overlays always act as if none were found.

I managed to get it to compile at last, but now I'm hitting another
issue. temacs segfaults in a gc while loading simple.el. It seems
somehow some memory doesn't look like it should, because the stack trace
from the gc is about 1100 frames! Mostly mark_object, with some
mark_vectorlike here and there. How do I debug something like that? I
tried putting a breakpoint in mark_buffer, but that function is called
like a million times, and from what I can see at least the first hundred
or so don't cause a crash.

When it crashes, it always seems to be on the 10th Lisp_Object in struct
buffer, which by my calculations is major_mode_. From there it seems to
go haywire and into a thousand or more calls to mainly_mark object.

I will try to investigate further, but any pointers (pun intended) would
be very much appreciated.

-- Jocke

reply via email to

[Prev in Thread] Current Thread [Next in Thread]