all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@permabit.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23397@debbugs.gnu.org
Subject: bug#23397: 25.0.92; assertion failure auto-reverting a file being overwritten
Date: Tue, 03 May 2016 17:04:24 -0400	[thread overview]
Message-ID: <6e8tzqdfaf.fsf@just-testing.permabit.com> (raw)
In-Reply-To: <83d1p3kw9y.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 03 May 2016 18:15:37 +0300")


Eli Zaretskii <eliz@gnu.org> writes:
> That is still better than aborting, right?

Of course. But it seems to me we should have the information we need to
keep the Emacs processing self-consistent whether we iterate or not.
Other code in the function already clearly expects that the number of
bytes we can read may be different from st_size.

(Arguably, in case we're trying to preserve point or markers in a later
part of the file than might have been rewritten so far, it might be
desirable for insert-file-contents to restart or pause briefly and retry
reading more content if it detects a change, but I think that's mostly a
separate question.)

I've finally reproduced the problem. A key issue was that the whole
block containing the failing code would be skipped by the conditional
below if the coding system were "undecided", which seems to be the norm
in my testing with "emacs -Q", but not in my working environment for
whatever reason; maybe one of the minor modes I've loaded is setting a
more specific coding system.

  if (!NILP (replace)
      && BEGV < ZV
      && (NILP (coding_system)
	  || ! CODING_REQUIRE_DECODING (&coding)))

If the coding system is "undecided-unix", we enter this block, and I can
get it to blow up.

Recipe:

Get two similar files differing in the middle; I started with emacs-25
charset.h:

    cp .../src/charset.h file.h
    sed -e 400,499s/a/b/g < file.h > file2.h

Set a breakpoint just after the fstat call in Finsert_file_contents,
run emacs -Q, and read in file.h (continuing whenever the breakpoint is
hit). Turn on auto-revert-mode in the buffer.

Set the coding system with "C-x RET f" to "undecided-unix". That marks
the buffer as modified, so clear that by saving the file.

Copy file2.h over file.h, and when the breakpoint is triggered, change
st.st_size to zero, to simulate rereading before the file overwriting
has finished, and continue. My debugging printfs show that an
out-of-range same_at_end is generated as in my original case:

    (gdb) c
    Continuing.
    Finsert_file_contents:3871: same_at_start=13993 same_at_end=17747
         st_size=0 ZV=19498
      => overlap=15743
      => new same_at_end=33490

    ../../src/marker.c:297: Emacs fatal error: assertion failed: BUF_BEG_BYTE (b) <= bytepos && bytepos <= BUF_Z_BYTE (b)





  reply	other threads:[~2016-05-03 21:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 22:05 bug#23397: 25.0.92; assertion failure auto-reverting a file being overwritten Ken Raeburn
2016-05-02 16:47 ` Eli Zaretskii
2016-05-02 20:43   ` Ken Raeburn
2016-05-03 15:15     ` Eli Zaretskii
2016-05-03 21:04       ` Ken Raeburn [this message]
2018-06-16 21:45     ` Noam Postavsky
2018-06-17  5:36       ` Eli Zaretskii
2020-09-05 14:03       ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e8tzqdfaf.fsf@just-testing.permabit.com \
    --to=raeburn@permabit.com \
    --cc=23397@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.