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: Tue, 17 Nov 2015 08:46:40 -0500 Message-ID: References: <83r3jpc2of.fsf@gnu.org> <87h9kkbz6k.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447768027 7091 80.91.229.3 (17 Nov 2015 13:47:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 13:47:07 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 14:46:52 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 1Zygax-0007fm-KH for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 14:46:51 +0100 Original-Received: from localhost ([::1]:58546 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zygax-0006Vg-2K for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 08:46:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zygau-0006VD-EA for emacs-devel@gnu.org; Tue, 17 Nov 2015 08:46:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zygat-0005Xz-Kt for emacs-devel@gnu.org; Tue, 17 Nov 2015 08:46:48 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:8251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zygap-0005WP-Qb; Tue, 17 Nov 2015 08:46:43 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcFgA731xV/++ZWxdSCoMQhAKFVbtAg2ODaAQCAoE8OhMBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA1SiAkIzyMBAQEHAgEfizqEKF0HhC0FjDCeS4oJI4QWIIJ4AQEB X-IPAS-Result: A0BcFgA731xV/++ZWxdSCoMQhAKFVbtAg2ODaAQCAoE8OhMBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA1SiAkIzyMBAQEHAgEfizqEKF0HhC0FjDCeS4oJI4QWIIJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="178465611" Original-Received: from 23-91-153-239.cpe.pppoe.ca (HELO pastel.home) ([23.91.153.239]) by ironport2-out.teksavvy.com with ESMTP; 17 Nov 2015 08:46:40 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 1ECD1623CB; Tue, 17 Nov 2015 08:46:40 -0500 (EST) In-Reply-To: <87h9kkbz6k.fsf@russet.org.uk> (Phillip Lord's message of "Tue, 17 Nov 2015 12:14:27 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:194642 Archived-At: >>> Debugging uncovered the following sequence of calls: >>> . 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. > I'm not sure how I would identify the "critical section". The "critical section" is the span of code during which the buffer is "being worked on" by the insertion function, so during this time, the buffer shouldn't be modified by anyone else in any way: no Elisp code should be run, no GC should take place. > At one point, this function call was actually a hook > (after-undoable-change-hook). Would this solve the problem? Nope, makes no difference. Stefan