From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25203: 25.1; crash during message, infinite recursion Date: Thu, 15 Dec 2016 17:55:50 +0200 Message-ID: <83fulp9oft.fsf@gnu.org> References: <20161215000453.17313-1-htl10@users.sourceforge.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1481817441 21686 195.159.176.226 (15 Dec 2016 15:57:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2016 15:57:21 +0000 (UTC) Cc: htl10@users.sourceforge.net, 25203@debbugs.gnu.org To: Hin-Tak Leung Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 15 16:57:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHYPA-0004WQ-7r for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Dec 2016 16:57:12 +0100 Original-Received: from localhost ([::1]:55395 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHYPE-0006Bw-JM for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Dec 2016 10:57:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHYP5-00061F-3P for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2016 10:57:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHYP3-0003lh-SQ for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2016 10:57:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55881) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cHYP0-0003k5-N7 for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2016 10:57:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cHYP0-0006OO-FU for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2016 10:57:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2016 15:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25203 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25203-submit@debbugs.gnu.org id=B25203.148181742124565 (code B ref 25203); Thu, 15 Dec 2016 15:57:02 +0000 Original-Received: (at 25203) by debbugs.gnu.org; 15 Dec 2016 15:57:01 +0000 Original-Received: from localhost ([127.0.0.1]:43047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHYOz-0006O9-6b for submit@debbugs.gnu.org; Thu, 15 Dec 2016 10:57:01 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHYOx-0006Ny-Mg for 25203@debbugs.gnu.org; Thu, 15 Dec 2016 10:57:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHYOp-0003bW-73 for 25203@debbugs.gnu.org; Thu, 15 Dec 2016 10:56:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHYOZ-0003Jf-NH; Thu, 15 Dec 2016 10:56:35 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1515 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cHYOY-0008It-Re; Thu, 15 Dec 2016 10:56:35 -0500 In-reply-to: <20161215000453.17313-1-htl10@users.sourceforge.net> (message from Hin-Tak Leung on Thu, 15 Dec 2016 00:04:53 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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: 208.118.235.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:127051 Archived-At: > From: Hin-Tak Leung > Date: Thu, 15 Dec 2016 00:04:53 +0000 > Cc: Hin-Tak Leung > > emacs -Q -batch -l cjk-enc.el -f batch-force-cjk-write-file Big5.tex > > where cjk-enc.el is a slight enhancement of > "cjk/utils/lisp/emacs/cjk-enc.el" from http://cjk.ffii.org , with > > diff --git a/emacs/cjk-enc.el b/emacs/cjk-enc.el > index c8e6706..096ade7 100644 > --- a/emacs/cjk-enc.el > +++ b/emacs/cjk-enc.el > @@ -881,7 +881,8 @@ > (setq last-pos (point)) > (message "Converting: %2d%%" > (/ (* 100 (point)) (point-max))))) > - > + (message "temp-buf is %s..." (buffer-name temp-buf)) > + (message "work-buf is %s..." (buffer-name work-buf)) > ;; Advance to the next character and loop. > (forward-char 1)) > > and Big5.tex is cjk/examples/Big5.tex AFAICT, cjk-enc.el shoots itself in the foot by invoking 'message' from the pre-write-conversion function. This is a very dangerous thing to do, as the analysis below shows. In fact, any I/O that might require encoding should be completely avoided in pre-write-conversion. It should be a function that does its work silently without any I/O, because it is invoked in a context of I/O. If it does need to do I/O, it absolutely must make sure that I/O will not use the same encoding for which the pre-write-conversion function was written. Here's what happens here: . cjk-enc defines a coding-system with a pre-write-conversion function cjk-encode. . batch-force-cjk-write-file eventually calls cjk-write-file, which does this: (message "Saving %s and %s" bufname newbufname) (let ((coding-system-for-write 'cjk-coding)) (write-region (point-min) (point-max) newbufname)) . write-region invokes cjk-encode as part of encoding the text in the region. . cjk-encode calls 'message', due to the above changes. . since this is batch mode, 'message' eventually calls message_to_stderr, which attempts to encode the text before writing it to the terminal. But since coding-system-for-write is let-bound to a non-nil value, message_to_stderr uses that value for encoding (as all the encoding functions do), and that results in recursive invocation of cjk-encode, which again tries to output a message to the terminal, etc. etc., ad nauseam. The simplest fix for this that requires no changes in Emacs core is this: (let ((coding-system-for-write locale-coding-system)) (message "temp-buf is %s..." (buffer-name temp-buf)) (message "work-buf is %s..." (buffer-name work-buf))) That is, wrap the above 'message' calls in a let-binding of coding-system-for-write that avoids recursion, and still does TRT wrt encoding messages to the terminal in batch mode. After all, this is (presumably) debugging code, so it can go some extra length to avoid interfering with the code it's supposed to debug. If someone is going to argue that Lisp code should never crash Emacs, then I can see the following alternatives: 1. Inhibit messages while calling pre-write-conversion. 2. Signal an error when pre-write-conversion is called recursively. I think none of these is a good idea, as they disallow perfectly valid use cases which don't hit this problem. The 2nd one is also error prone in its naïve implementation, and too complex IMO in non-naïve ones. So my suggestion is to fix your debugging code as indicated above. Thanks.