[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening
From: |
Eli Zaretskii |
Subject: |
bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening |
Date: |
Fri, 03 Oct 2014 15:20:46 +0300 |
> Date: Fri, 03 Oct 2014 15:22:12 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Eli Zaretskii <eliz@gnu.org>, 18610@debbugs.gnu.org,
> maden.ldm@gmail.com
>
> There is a reduced sample which is just 194 bytes (attached).
Thanks, I also arrived at such a shortened version.
But the shortest version is just this:
1B 96
IOW, you need an escape and a raw byte between 128 and 159
(inclusive).
> The whole thing is really subtle: when detect_coding is called, it finds (1)
> and
> calls to detect_coding_iso_2022, which returns 1. Since this happens before
> detect_coding finds (2), this function assumes that the whole data is in one
> of
> 7-bit (?) ISO-2022 encoding. Thus, no conversion is performed, and
> decode_coding_gap
> inserts the data as is; this way we end up with 96 3B byte sequence in buffer
> text.
Indeed. But I don't think we can simply reject ISO-2022 here, because
the mere presence of bytes in [128..159] is not supposed to reject the
possibility of decoding that text by ISO-2022, see
latin-extra-code-table.
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?
=== modified file 'src/coding.c'
--- src/coding.c 2014-08-06 17:37:22 +0000
+++ src/coding.c 2014-10-03 12:09:28 +0000
@@ -6559,7 +6559,8 @@ detect_coding (struct coding_system *cod
&& ! inhibit_ied
&& ! detect_info.checked)
{
- if (detect_coding_iso_2022 (coding, &detect_info))
+ if (detect_coding_iso_2022 (coding, &detect_info)
+ && detect_info.found != 0)
{
/* We have scanned the whole data. */
if (! (detect_info.rejected & CATEGORY_MASK_ISO_7_ELSE))
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, maden . ldm, 2014/10/02
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Nicolas Richard, 2014/10/02
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Dmitry Antipov, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening,
Eli Zaretskii <=
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Andreas Schwab, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Andreas Schwab, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Andreas Schwab, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, K. Handa, 2014/10/05
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/05
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, K. Handa, 2014/10/06