From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#36431: Crash in marker.c:337 Date: Tue, 02 Jul 2019 13:04:38 -0400 Message-ID: References: <20190629.131734.877718102639559715.wl@gnu.org> <831rzch9nd.fsf@gnu.org> <83zhm0fuqg.fsf@gnu.org> <83ftnrf87e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="112203"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 36431@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 02 20:32:53 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hiNaF-000T0f-By for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 20:32:51 +0200 Original-Received: from localhost ([::1]:56194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiNaE-0003eg-3Z for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 14:32:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56205) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiMDH-00063i-R0 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:05:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiMDG-0000DH-E4 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:05:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38999) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiMDG-0000D7-Ar for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiMDG-0006Xu-4a for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:05: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, 02 Jul 2019 17:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36431 X-GNU-PR-Package: emacs Original-Received: via spool by 36431-submit@debbugs.gnu.org id=B36431.156208709025130 (code B ref 36431); Tue, 02 Jul 2019 17:05:02 +0000 Original-Received: (at 36431) by debbugs.gnu.org; 2 Jul 2019 17:04:50 +0000 Original-Received: from localhost ([127.0.0.1]:47820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiMD4-0006XF-E1 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 13:04:50 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiMD2-0006Wg-IE for 36431@debbugs.gnu.org; Tue, 02 Jul 2019 13:04:49 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5E532100B3B; Tue, 2 Jul 2019 13:04:42 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B289110087A; Tue, 2 Jul 2019 13:04:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1562087080; bh=d3NWP9hWyyv4t7QV++Ay9ve7Z0MhHrJuSMgCiZ5Yj5A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=eU+19RA/L6DUHpWU71+LHT83HB/UuuePu2qqWnZ+HFhtPLK7O75u85E+XseHGKri3 pmJL6M1F8v498i5+TGUOsx38Sm7+IEvtO5+8Lojy0EmnTzz2SemmzkFq8M2syIC6xo ycKBNMV8+d2SEXiuzU7fd9NGgIVMlJahmp2y/vywmRiwpZQE5r5lttt9QLh7K0ADnx B9hParGlNphgw5tPe6NISvSkKvuwSDDXATDRqDl4Rlze3riyToZq8wMV0Vhzqo2ME0 Et09m2JioOphB9IuAWIXRicf0bGIBQA/rIZWHlbSrdR8lXDCUh+NML/+W3iVEKPRiC TwvVVD87HzRDw== Original-Received: from pastel (76-10-151-214.dsl.teksavvy.com [76.10.151.214]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7813C1201A4; Tue, 2 Jul 2019 13:04:40 -0400 (EDT) In-Reply-To: <83ftnrf87e.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Jun 2019 17:39:49 +0300") 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: 209.51.188.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:161973 Archived-At: >> I don't really know how to reproduce your bug, but I think I have an >> idea of what might be going on. >> Can you try the patch below, to see if it fixes your problem? > AFAICT, this patch moves the call to move_gap_both from a fragment > where we must decode the inserted text to a fragment where such a > decoding might not be necessary. If I'm right, then this makes > insert-file-contents slower in some cases, because moving the gap > might be very expensive with large buffers. Indeed. It also removed the move_gap_both from the case where we need to decode and we already know the coding-system to use. So in some cases it made it faster (these are the cases where it misbehaved). The new version of the code shouldn't suffer from this performance problem (it still calls move_gap_both in the set-auto-coding part of the code, but this call should have a cost proportional to the amount of buffer modification performed by set-auto-coding, i.e. it should be a nop in pretty much all cases). Looking at this aspect (i.e. not directly related to this bug) I'm wondering why the code works this way: We start by inserting the new bytes at the *beginning* of the gap, but when we do the move_gap_both this moves those bytes to the *end* of the gap (where decode_coding_gap expects them, apparently), so when we decode we always have to move all the inserted bytes, right? > More generally, I'd be leery to make significant changes ion > insert-file-contents just to placate that single assertion. What do > we gain with that assertion except some theoretical correctness? Again, I'm just trying to understand the code at this point. The part that worries me is the following: In the current code, we read the raw bytes to the beginning of the gap, then (when Vset_auto_coding_function needs to be called), we (virtually) move them into the current buffer, which is usually multibyte. AFAICT at this point we have a buffer in a transiently inconsistent state since it's multibyte but it can contain arbitrary byte sequences, hence invalid byte sequences. Before calling Vset_auto_coding_function we make this buffer unibyte, which brings us back to a consistent state, but I wonder if/how/why making the buffer unibyte and then back to multibyte always preserves the original byte sequence, since AFAICT set-buffer-multibyte will always make the effort to bring the buffer to a consistent state, so if the state is inconsistent before the pair of calls to set-buffer-multibyte, either we changed the byte sequence or set-buffer-multibyte doesn't always result in a consistent state. What am I missing? Stefan