From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Calling Lisp from undo.c's record_* functions Date: Tue, 17 Nov 2015 12:14:27 +0000 Message-ID: <87h9kkbz6k.fsf@russet.org.uk> References: <83r3jpc2of.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447762487 12956 80.91.229.3 (17 Nov 2015 12:14:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 12:14:47 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 13:14:43 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 1Zyf9k-0002Po-Uo for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 13:14:41 +0100 Original-Received: from localhost ([::1]:57831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyf9k-000830-FQ for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 07:14:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyf9g-000825-3R for emacs-devel@gnu.org; Tue, 17 Nov 2015 07:14:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyf9f-0000sm-4i for emacs-devel@gnu.org; Tue, 17 Nov 2015 07:14:36 -0500 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:43150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyf9Z-0000r9-ML; Tue, 17 Nov 2015 07:14:29 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1Zyf9Y-00035n-C8; Tue, 17 Nov 2015 12:14:28 +0000 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Zyf9X-0000AG-Lg; Tue, 17 Nov 2015 12:14:27 +0000 In-Reply-To: (Stefan Monnier's message of "Mon, 16 Nov 2015 17:51:43 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:194639 Archived-At: Stefan Monnier writes: >> 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". At one point, this function call was actually a hook (after-undoable-change-hook). Would this solve the problem? > >> 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. I've pushed an unfinished fix to fix/segfault-from-run-undoable-change I'm pretty sure my implementation in C could be simpler. I wasn't sure how to get from the current-buffer variable in C, to the Lisp_Object, so in the end, I just called Fcurrent_buffer. The second part of the plan is to change simple.el to use a idle timer, as I suggested yesterday. I'll do that later today. At the moment, I can't replicate the problem, though. Phil