From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening Date: Sun, 05 Oct 2014 19:09:26 +0300 Message-ID: <83zjdamrbd.fsf@gnu.org> References: <871tqmevsu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1412525425 20526 80.91.229.3 (5 Oct 2014 16:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Oct 2014 16:10:25 +0000 (UTC) Cc: dmantipov@yandex.ru, maden.ldm@gmail.com, 18610@debbugs.gnu.org To: handa@gnu.org (K. Handa) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 05 18:10:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1XaoO1-00064Q-Sh for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Oct 2014 18:10:18 +0200 Original-Received: from localhost ([::1]:47947 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XaoO1-0004x8-9a for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Oct 2014 12:10:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XaoNt-0004vQ-1y for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 12:10:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XaoNn-00063S-O4 for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 12:10:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XaoNn-000631-KZ for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 12:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XaoNm-0008AE-Ve for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 12:10:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Oct 2014 16:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18610 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18610-submit@debbugs.gnu.org id=B18610.141252536531335 (code B ref 18610); Sun, 05 Oct 2014 16:10:02 +0000 Original-Received: (at 18610) by debbugs.gnu.org; 5 Oct 2014 16:09:25 +0000 Original-Received: from localhost ([127.0.0.1]:34841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XaoNA-00089L-LF for submit@debbugs.gnu.org; Sun, 05 Oct 2014 12:09:25 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:40372) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XaoN8-00089C-4D for 18610@debbugs.gnu.org; Sun, 05 Oct 2014 12:09:23 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NCZ00L00BAK9G00@a-mtaout22.012.net.il> for 18610@debbugs.gnu.org; Sun, 05 Oct 2014 19:09:20 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCZ00KWWBJKVY70@a-mtaout22.012.net.il>; Sun, 05 Oct 2014 19:09:20 +0300 (IDT) In-reply-to: <871tqmevsu.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:94170 Archived-At: > From: handa@gnu.org (K. Handa) > Date: Sun, 05 Oct 2014 17:59:45 +0900 > Cc: dmantipov@yandex.ru, maden.ldm@gmail.com, 18610@debbugs.gnu.org > > > However, detect_coding_iso_2022 returns with the 'found' member of its > > second argument having zero value, which I interpret as meaning that > > it didn't really find any ISO-2022 sequences. So the simple patch > > below fixes this for me. Kenichi, is this patch OK? > > No. Even if there's no special ISO-2022 escape sequence, we > should not reject iso-2022 as a detected coding system. Can you explain why? AFAICT, all the other detectors are required to set some flag in the 'found' field, so why is ISO-2022 special in this regard? > And, even if that detection was incorrect, the decoder > should not produce an invalid byte sequence in a > buffer/string which leads to Emacs crash. No argument here. > The bug is in detect_coding_iso_2022 which doesn't set > CATEGORY_MASK_ISO_7_ELSE in coding->rejected in this case. Btw, it would be nice if these masks could be documented so that their meaning was clear. I considered the possibility that the flags are not set correctly, but couldn't test that hypothesis given my insufficient knowledge of ISO-2022 details and variants. > I've just installed a fix to trunk. Could you please try > the latest version? It fixes the crash, but I'm not sure the results are what we want. Emacs 24.3, which also did not crash, would set the buffer-file-coding-system of the buffer visiting the file to 'undecided', and regarded the \226 characters as 8-bit raw bytes: character: \226 (displayed as \226) (codepoint 4194198, #o17777626, #x3fff96) ... general-category: Cn (Other, Not Assigned) By contrast, the current trunk sets buffer-file-coding-system to 'latin-1' and thinks this character is a Latin-1 character: character: \226 (displayed as \226) (codepoint 150, #o226, #x96) preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1)) ... old-name: START OF GUARDED AREA general-category: Cc (Other, Control) That doesn't sound right to me. If I force some specific coding system, e.g. C-x RET c utf-8 RET C-x C-f FILE RET then the \226 characters are correctly recognized as 8-bit bytes by the current trunk (as was the case before your changes). Could it be that the current trunk fails to recognize the 8-bit bytes in the file?