From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#20440: 24.4; memory corruption Date: Tue, 28 Apr 2015 09:51:04 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430229157 15129 80.91.229.3 (28 Apr 2015 13:52:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 13:52:37 +0000 (UTC) Cc: 20440@debbugs.gnu.org To: Neal Becker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 28 15:52:26 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 1Yn5vs-0005bE-GI for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 15:52:16 +0200 Original-Received: from localhost ([::1]:33486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn5vr-0003GV-Uz for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 09:52:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn5vk-000391-28 for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 09:52:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yn5ve-0007fd-Pd for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 09:52:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn5ve-0007fZ-Md for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 09:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yn5ve-0001I3-8W for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 09:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 13:52:02 +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.14302290754899 (code B ref 20440); Tue, 28 Apr 2015 13:52:02 +0000 Original-Received: (at 20440) by debbugs.gnu.org; 28 Apr 2015 13:51:15 +0000 Original-Received: from localhost ([127.0.0.1]:42184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn5ur-0001Gw-Sv for submit@debbugs.gnu.org; Tue, 28 Apr 2015 09:51:14 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39809) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn5uo-0001Gi-8b for 20440@debbugs.gnu.org; Tue, 28 Apr 2015 09:51:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRMCqjW/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOChwSFBgNJBOIAKIRjCFDg00DJ4NJBKNjhFg X-IPAS-Result: AgUFAGvvdVRMCqjW/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOChwSFBgNJBOIAKIRjCFDg00DJ4NJBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117677866" Original-Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2015 09:51:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7C8E7CC6; Tue, 28 Apr 2015 09:51:04 -0400 (EDT) In-Reply-To: (Neal Becker's message of "Tue, 28 Apr 2015 07:01:16 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) 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:102159 Archived-At: > There are exactly the same length > In 2 tests it happened 2 times. So probably is reproducible. If you can come up with a reproducible recipe, then please do so. Stefan > 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*