From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36431: Crash in marker.c:337 Date: Tue, 02 Jul 2019 21:27:15 +0300 Message-ID: <83sgrocmws.fsf@gnu.org> References: <20190629.131734.877718102639559715.wl@gnu.org> <831rzch9nd.fsf@gnu.org> <83zhm0fuqg.fsf@gnu.org> <83ftnrf87e.fsf@gnu.org> <83v9wkcp3z.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="200554"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36431@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 02 21:58:50 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 1hiOvR-000q0R-7B for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 21:58:49 +0200 Original-Received: from localhost ([::1]:56880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiOvQ-0008VM-7F for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 15:58:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57957) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiNVc-0008Po-Qm for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:28:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiNVa-0003yV-Cp for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39097) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiNVa-0003yG-92 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiNVa-0000pM-3R for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 18:28: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.15620920733161 (code B ref 36431); Tue, 02 Jul 2019 18:28:02 +0000 Original-Received: (at 36431) by debbugs.gnu.org; 2 Jul 2019 18:27:53 +0000 Original-Received: from localhost ([127.0.0.1]:47918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiNVO-0000os-47 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 14:27:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiNVL-0000og-BQ for 36431@debbugs.gnu.org; Tue, 02 Jul 2019 14:27:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hiNVF-0003Ax-6N; Tue, 02 Jul 2019 14:27:41 -0400 Original-Received: from [176.228.60.248] (port=3212 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hiNVA-0004rT-N0; Tue, 02 Jul 2019 14:27:38 -0400 In-reply-to: (message from Stefan Monnier on Tue, 02 Jul 2019 13:51:30 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:161982 Archived-At: > From: Stefan Monnier > Cc: wl@gnu.org, 36431@debbugs.gnu.org > Date: Tue, 02 Jul 2019 13:51:30 -0400 > > - we insert the new bytes at the beginning of the gap, in order to have > room to grow if there are more bytes than expected, and also in case > there are fewer bytes than expected (in which case we'd otherwise > have to move the bytes we just read so they properly end at the end > of the gap). Also, you will see in insert-file-contents that it supports quitting while reading a huge file, and also the REPLACE argument, where we detect the same contents at beginning and end of the file and the buffer. > - decode_coding_gap wants the new input bytes to be at the end of the > gap, so that we can put the decoded chars at the beginning of the gap > and as one grows the other shrinks, so we don't need space for "IN + > OUT" bytes but only for "OUT" bytes. Is that right (I'm trying to > find some comment or other evidence that this is the case, but > haven't found it yet). That's right. The comment you are looking for (well, at least part of it) is in the commentary before decode_coding, where it explains the semantics of CODING->src_pos. You will see at the beginning of decode_coding_gap how it sets things up according to that hairy protocol. > IOW, it should be possible to optimize the common case by reading the > new bytes into the end of the gap to avoid moving everything in the > common case (if the number of bytes read is different from originally > expected, we'll have to do extra work, but for the common case where we > know the file size upfront and it doesn't change while we read it, this > will save us some work). > > But the effort is probably not worth the trouble: a memmove of a few > gigabytes costs relatively little compared to the cost of actually > decoding those same gigabytes. Right. Also, there are the other subtle issues with quitting, the REPLACE argument, special files, etc.