From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#23397: 25.0.92; assertion failure auto-reverting a file being overwritten Date: Mon, 02 May 2016 16:43:12 -0400 Message-ID: <6efuu0chsv.fsf@just-testing.permabit.com> References: <6epot9crti.fsf@just-testing.permabit.com> <83vb2wl83m.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1462221883 627 80.91.229.3 (2 May 2016 20:44:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 May 2016 20:44:43 +0000 (UTC) Cc: 23397@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 02 22:44:31 2016 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 1axKhj-0007hN-31 for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 May 2016 22:44:31 +0200 Original-Received: from localhost ([::1]:38445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axKhf-0008R3-B5 for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 May 2016 16:44:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axKhW-0008E8-BU for bug-gnu-emacs@gnu.org; Mon, 02 May 2016 16:44:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axKhK-0002WU-C9 for bug-gnu-emacs@gnu.org; Mon, 02 May 2016 16:44:12 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axKhJ-0002VC-5t for bug-gnu-emacs@gnu.org; Mon, 02 May 2016 16:44:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1axKhF-0006DO-QH for bug-gnu-emacs@gnu.org; Mon, 02 May 2016 16:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 May 2016 20:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23397 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23397-submit@debbugs.gnu.org id=B23397.146222180223833 (code B ref 23397); Mon, 02 May 2016 20:44:01 +0000 Original-Received: (at 23397) by debbugs.gnu.org; 2 May 2016 20:43:22 +0000 Original-Received: from localhost ([127.0.0.1]:34241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1axKgc-0006CL-Ir for submit@debbugs.gnu.org; Mon, 02 May 2016 16:43:22 -0400 Original-Received: from mail-qk0-f175.google.com ([209.85.220.175]:32919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1axKga-0006C9-Mp for 23397@debbugs.gnu.org; Mon, 02 May 2016 16:43:20 -0400 Original-Received: by mail-qk0-f175.google.com with SMTP id n63so33804qkf.0 for <23397@debbugs.gnu.org>; Mon, 02 May 2016 13:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=uHhgFTbdjvYIqhvE7FZX6YqHsr30DMCnCzHQ7SGD9zE=; b=BwKnEkLS2QJG7565em2S1BCJW5mr+826B9Kb7eum9nWdbjIUTZKp/YRZanqmRndDmK bZM6zoU/xWnHrv/pRPi0DdnYcB6ZheP86rfXL71OSqljqCzpagoRcoW1TwfC6CIlaN8g Z36/F+1TtJsDPl5g6Dv2yuxy4xQkSS/JPVQ6w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=uHhgFTbdjvYIqhvE7FZX6YqHsr30DMCnCzHQ7SGD9zE=; b=bpT2UJjpOBun/s7e3loQma2Va63fBryNoE0hjkzFQU57zNXu/LU5gzc8M7r4vjCx0p jZPhxMWpca1way6RxR+91r5m4A8G6JhMXcaXpl/6prcv04O5knMU1/hr02eWeTRhBz78 yV6HsfP9l0YsUd142aDQyzbtFpwI0+A2+q1U5Z2EPoAMKDUD5lXhixJbxZd3fY7r01O1 83hkh+oApl1GHbd7gZhVS0oBD/e1gRrSsTeVkQqRhe4RCX1BQOTL4VBwhdoD8tyKoyFN cGpgoHelRwJOWi9oCV9yL8EBc4fZEa4ocwH/Vh1LGp9RUfLzHi7KtKjFMAjrRI2EDrbH 3Ljw== X-Gm-Message-State: AOPr4FXaeiVVyi/qO119lYZKV1r6BvkQUcQifjzHVzs5PbMsv7sjebR2h0lXZyBhz3gQXhK4 X-Received: by 10.55.41.159 with SMTP id p31mr12154238qkp.36.1462221795005; Mon, 02 May 2016 13:43:15 -0700 (PDT) Original-Received: from just-testing.permabit.com (vpn.permabit.com. [66.202.84.2]) by smtp.gmail.com with ESMTPSA id y129sm9780964qka.33.2016.05.02.13.43.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 13:43:13 -0700 (PDT) In-Reply-To: <83vb2wl83m.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 02 May 2016 19:47:57 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:117614 Archived-At: Eli Zaretskii writes: > So you are saying that the file's contents was updated between the > time we called 'fstat' at the beginning of the function and the time > we used st.st_size in the above snippet? That's my guess. Or, more specifically, between the fstat and attempting to go ahead and read data anyway. But I did a few experiments with truncating the file and using a breakpoint after the fstat to stall Emacs while I restored the file (so the size appeared to be zero but all the data was readable), and nothing interesting happened. That part of the function seems to be trying to figure out if some of the beginning and end of the file are unchanged from before, so I think maybe it also requires having some part in the middle changed, or one version of the file being shorter than the other. I'll run a few more experiments today to see. > If so, perhaps we should call 'fstat' again each time we want to use > st.st_size, and retry from the beginning if we find a mismatch? If the file is large, and being frequently updated in small increments, that could delay us considerably, as we restart the process multiple times. (Some of the files I use auto-revert mode on are log files in the tens of megabytes. Last I tried, auto-revert-tail-mode didn't cope nicely with the case where the file got truncated and rewritten, so reverting the whole file seems to be the way to go for now.) And if we put a limit on the number of iterations, the last time around we'll still need to get it right. There's code there doing lseek and read calls; we should be able to keep track of the last file position we read from, if that's not already derivable from existing variables visible at that point.