From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Calling Lisp from undo.c's record_* functions Date: Mon, 16 Nov 2015 17:51:43 -0500 Message-ID: References: <83r3jpc2of.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447722495 4006 80.91.229.3 (17 Nov 2015 01:08:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 01:08:15 +0000 (UTC) Cc: emacs-devel@gnu.org, Phillip Lord To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 02:08:05 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZyUkd-0003gz-MQ for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 02:08:03 +0100 Original-Received: from localhost ([::1]:54185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyUkd-0006aW-3u for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 20:08:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyScp-0008Cf-H9 for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:51:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZySck-0002pe-Hp for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:51:51 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZySck-0002oQ-CP; Mon, 16 Nov 2015 17:51:46 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id tAGMphu7026369; Mon, 16 Nov 2015 17:51:43 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 48E77AE21A; Mon, 16 Nov 2015 17:51:43 -0500 (EST) In-Reply-To: <83r3jpc2of.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 Nov 2015 18:46:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5492=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5492> : inlines <4003> : streams <1539260> : uri <2084148> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194612 Archived-At: > Debugging uncovered the following sequence of calls: > . some Lisp calls 'insert' whose argument is a 12K string > . this eventually calls insert_from_string_1, which enlarges the > buffer gap to accommodate for the inserted text > . in the midst of manipulating the gap, insert_from_string_1 calls > record_insert > . record_insert calls record_point, which calls run_undoable_change, > which calls Lisp > . the Lisp interpreter decides it's a good time to GC and calls > garbage_collect > . garbage_collect calls compact_buffer, which decides the buffer in > which the insertion happened can be compacted (since the gap > manipulation is not yet done, and it looks like the buffer has a > lot of slack space), so it shrinks the gap > . bottom line: the gap was shrunk behind the back of > insert_from_string_1, which totally doesn't expect that, and > proceeds doing silly things, like setting the gap size to a large > negative value, and from there we are on a certain and very short > path to a crash Duh! > My dilemma is: how to fix this cleanly and correctly? Not sure what's the best solution, but the precise moment when run_undoable_change is executed is not terribly important, so if we could just move it to either before or after the "critical section", then that would be a good solution. > Question #1: do we really need to call Lisp from so deep inside the > bowels of buffer manipulation routines? Is that safe? Perhaps we > should reimplement undo-auto--undoable-change inC? That should work, yes. > Question #2: one solution is inhibit GC in run_undoable_change. But > since that could run arbitrary Lisp, is that a good idea? what if we > run out of memory? Nah, that'd be too ugly and brittle. > Question #3: another possible solution is to set the current buffer's > inhibit_shrinking flag around the call to Lisp in run_undoable_change > -- is this better? Note that this won't prevent GC in general, so the > follow-up question is can insdel.c functions afford a GC while they > run? That also sounds risky. Stefan