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:51:30 -0400 Message-ID: References: <20190629.131734.877718102639559715.wl@gnu.org> <831rzch9nd.fsf@gnu.org> <83zhm0fuqg.fsf@gnu.org> <83ftnrf87e.fsf@gnu.org> <83v9wkcp3z.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="15589"; 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 21:14:05 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 1hiOE9-0003d8-67 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 21:14:05 +0200 Original-Received: from localhost ([::1]:56402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiO7q-00022D-K5 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 15:07:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43551) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiMwr-0004Zq-5B for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:52:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiMwo-00045C-AO for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:52:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39051) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiMwk-00042n-6y for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiMwk-0008NY-3T for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 13: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, 02 Jul 2019 17:52: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.156208990032177 (code B ref 36431); Tue, 02 Jul 2019 17:52:02 +0000 Original-Received: (at 36431) by debbugs.gnu.org; 2 Jul 2019 17:51:40 +0000 Original-Received: from localhost ([127.0.0.1]:47872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiMwO-0008Mv-I3 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 13:51:40 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiMwN-0008Mi-Gd for 36431@debbugs.gnu.org; Tue, 02 Jul 2019 13:51:39 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1FCE5444462; Tue, 2 Jul 2019 13:51:33 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C78E8441B83; Tue, 2 Jul 2019 13:51:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1562089891; bh=3NHfX4Vw93MTGiiRvaWWfSmCqD75bDdHS+a+XYpCSwE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=L9n7Rtmulwq/xREiGs2y5V80WyP3KfF9zhvOrJzIfYPE80kvQsHgQKhWvDbF5Os3g KXflePaxeCzwwJaiVv94lYs2F3TecExEk1m/gxOSpvo2SYzL3Ex1P8Ky9cCMC4eXhJ fNbIxOJPis+AQdwK4P1smrowDgROvE32qT0ciKn3lxbdrhOWnWSxICPfJ60mHxlJFh qp2Q5fPkeR7v9vNMLOIXWfLtgj5GDZThqg93ke1hdEYE5PAZzOqhUpnQ6S/KyJzgWe KPUX591M8HKiK+E/tmCrfJ3Lhppcawk8+X5qKAw+06CLYZ+1EuDPiBVyZtLQjw3me1 0H7xSuy4/b/uw== Original-Received: from pastel (76-10-151-214.dsl.teksavvy.com [76.10.151.214]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8DFD11205E0; Tue, 2 Jul 2019 13:51:31 -0400 (EDT) In-Reply-To: <83v9wkcp3z.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Jul 2019 20:39:44 +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:161975 Archived-At: >> 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? > > Yes. This is so we don't need to know up front how many bytes will be > read from the file. OK, so IIUC: - 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). - 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). 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. Stefan