bug#20440: 24.4; memory corruption

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> after-change-functions is a variable defined in `C source code'.
> Its value is (jit-lock-after-change jedi:after-change-handler t)
> Local in buffer test_unframed.py; global value is nil

Hmm... could it be that jedi:after-change-handler does something funny?
Tho it seems rather unlikely: when it gets run, the revert has
already happened!

> I have captured a corrupt buffer.  This time, emacs said 'file has changed,
> reload?'.  Again it is corrupted.
> The 1st diff is that in the corrupted file, the beginning of the file is
> inserted into the middle of the buffer

Normally revert compares the buffer's content and the file's content
(from both ends) to find the common "prefix" and "suffix" and only
performs the update on the characters in-between.  IOW the beginning of
the buffer/file is not touched and the end is not touched either.

So rather than "the beginning of the file is inserted into the middle of
the buffer" it sounds like the "characters in-between" end up being
inserted at the beginning of the buffer.

Was the region active when the revert happened?

Is the total size of the corrupted file correct? (i.e. the update was
just not inserted at the right place)

What can you say about the "splice points" (i.e. those positions in the
file where the corruption happens: IIUC there's one at the very
beginning, but where are the others (e.g. where is the "real
beginning", in the corrupted file))?

How frequently does it happen?  (i.e. would you be able to notice if it
doesn't happen any more, after we disable some feature)


        Stefan


> On Mon, Apr 27, 2015 at 1:39 PM, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:

>> > I have seen (again this morning) I wind up with a corrupted buffer.
>> > It appears a segment of the data is correct, but data has been
>> > reordered.  I'm looking at a python source file.  For example, in the
>> > middle of the buffer, it looks like the beginning of the file is
>> > inserted (sorry I no longer have this buffer and can't be precise).
>> 
>> Next time it happens, could you save the corrupted buffer to some temp
>> file, and then compare that with the actual file's content, to get
>> a more precise description of the corruption?
>> 
>> You say it's a Python file.  What modes/packages do you use to edit
>> those files?  What does `M-: after-change-functions' and `M-:
>> before-change-functions' say in those buffers?
>> 
>> 
>> Stefan
>> 



> -- 
> *Those who don't understand recursion are doomed to repeat it*