From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Calling Lisp from undo.c's record_* functions Date: Mon, 16 Nov 2015 18:46:40 +0200 Message-ID: <83r3jpc2of.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447716631 15845 80.91.229.3 (16 Nov 2015 23:30:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2015 23:30:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier , Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 00:30:22 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 1ZyTE5-0006H4-V0 for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 00:30:22 +0100 Original-Received: from localhost ([::1]:51872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyTE4-000304-Tn for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 18:30:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyMvY-0006fd-3F for emacs-devel@gnu.org; Mon, 16 Nov 2015 11:46:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyMvV-0005vO-Bg for emacs-devel@gnu.org; Mon, 16 Nov 2015 11:46:48 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:35720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyMvU-0005uO-V2 for emacs-devel@gnu.org; Mon, 16 Nov 2015 11:46:45 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NXX00M002FYG300@mtaout25.012.net.il> for emacs-devel@gnu.org; Mon, 16 Nov 2015 18:44:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXX00K3B2HO5J20@mtaout25.012.net.il>; Mon, 16 Nov 2015 18:44:12 +0200 (IST) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.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:194582 Archived-At: Bootstrapping Emacs crashed on me today while building python-wy.el. Emacs segfaulted while trying to access memory outside its address space. 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 This was caused by a recent change that added a call to run_undoable_change to various functions in undo.c that record changes; run_undoable_change calls a Lisp function. My dilemma is: how to fix this cleanly and correctly? The record_* functions that are affected by this are called from quite a few places, most of them in insdel.c, but some in other places. I didn't audit all of them, but those I did generally manipulate the gap and have C pointers to buffer text lying around, because they don't expect any Lisp to be run or GC to happen. All of those places are now living dangerously. 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? 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? 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? Comments? Suggestions? TIA