From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neal Becker Newsgroups: gmane.emacs.bugs Subject: bug#20440: 24.4; memory corruption Date: Tue, 28 Apr 2015 07:01:16 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113deff2158e140514c6c8eb X-Trace: ger.gmane.org 1430218949 32714 80.91.229.3 (28 Apr 2015 11:02:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 11:02:29 +0000 (UTC) Cc: 20440@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 28 13:02:18 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yn3HO-0003Z0-7G for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 13:02:18 +0200 Original-Received: from localhost ([::1]:60471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn3HN-000210-Gl for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 07:02:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn3HF-0001tx-5W for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 07:02:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yn3HA-0002dk-1m for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 07:02:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn3H9-0002df-Vl for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 07:02:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yn3H9-0004Of-7b for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 07:02:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Neal Becker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 11:02:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20440 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20440-submit@debbugs.gnu.org id=B20440.143021889016863 (code B ref 20440); Tue, 28 Apr 2015 11:02:03 +0000 Original-Received: (at 20440) by debbugs.gnu.org; 28 Apr 2015 11:01:30 +0000 Original-Received: from localhost ([127.0.0.1]:42122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn3GY-0004Nr-Ok for submit@debbugs.gnu.org; Tue, 28 Apr 2015 07:01:29 -0400 Original-Received: from mail-ob0-f176.google.com ([209.85.214.176]:33814) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn3GU-0004Nd-Bp for 20440@debbugs.gnu.org; Tue, 28 Apr 2015 07:01:24 -0400 Original-Received: by obfe9 with SMTP id e9so105083039obf.1 for <20440@debbugs.gnu.org>; Tue, 28 Apr 2015 04:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HXWuKIcxU+i72FPX/ESC053l0xvC1UAHsvzjFXdGwHA=; b=0RFXLwZ56gcqQGCEAYD+U16bzQQAHpJ+R5sIYn63wL/RCBPqVZgbHm9RsK0QKzq30t uJc3e+Ju4mDutMZPHSV5sQqpO6JuRhuqUvY8Xz7vxqRiIG2Em2etFpswlcI7J4sqsPV5 8VU5mpakHkoK92AjwfYM1/dqdmy6AnMcdjsRcUx5RP3MzwNw+N8SM3mpOND2p0N91UWX ++4+SgPz6+Y2zWJeDJPHC6a/Mk7B6KKjBonA1JZVvMOfCqQjHUVwWQcmPBee9nKEYFeS 3d3m898YewPLdxxCpfENpBrZDQvEISOYirXMIydIBw0ZPYWpgBZ6isY1GqFTMkzbegBa M70w== X-Received: by 10.202.83.202 with SMTP id h193mr13127416oib.56.1430218876487; Tue, 28 Apr 2015 04:01:16 -0700 (PDT) Original-Received: by 10.76.24.69 with HTTP; Tue, 28 Apr 2015 04:01:16 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102155 Archived-At: --001a113deff2158e140514c6c8eb Content-Type: text/plain; charset=UTF-8 There are exactly the same length In 2 tests it happened 2 times. So probably is reproducible. On Mon, Apr 27, 2015 at 3:48 PM, Stefan Monnier wrote: > > 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* > -- *Those who don't understand recursion are doomed to repeat it* --001a113deff2158e140514c6c8eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are exactly the same length

In 2 = tests it happened 2 times.=C2=A0 So probably is reproducible.

On M= on, Apr 27, 2015 at 3:48 PM, Stefan Monnier <monnier@iro.umontrea= l.ca> wrote:
> 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 fun= ny?
Tho it seems rather unlikely: when it gets run, the revert has
already happened!

> I have captured a corrupt buffer.=C2=A0 This time, emacs said 'fil= e has changed,
> reload?'.=C2=A0 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&quo= t; and only
performs the update on the characters in-between.=C2=A0 IOW the beginning o= f
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 u= p 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?=C2=A0 (i.e. would you be able to notice if i= t
doesn't happen any more, after we disable some feature)


=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 b= uffer.
>> > It appears a segment of the data is correct, but data has bee= n
>> > reordered.=C2=A0 I'm looking at a python source file.=C2= =A0 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.=C2=A0 What modes/packages do you u= se to edit
>> those files?=C2=A0 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*



--
Those who don't understand rec= ursion are doomed to repeat it
--001a113deff2158e140514c6c8eb--