bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening

[Dmitry Antipov <dmantipov@yandex.ru>]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

On 10/03/2014 12:14 PM, Eli Zaretskii wrote:

> I'll continue looking into this.

There is a reduced sample which is just 194 bytes (attached).
This file has the following structure (hex bytes):

3B 19 5B 07 6F 3A 1B 53 61 73 73 3A 3A 53 65 6C 65 63 74 6F 72 3A 3A 50 61 72 65 6E
                   ^^
                   escape (1)
74 07 3A 0E 40 66 69 6C 65 6E 61 6D 65 22 00 3B 14 69 1A 6F 3A 1B 53 61 73 73 3A 3A
53 65 6C 65 63 74 6F 72 3A 3A 50 73 65 75 64 6F 0A 3B 0B 5B 06 22 0A 68 6F 76 65 72
3B 12 3A 0A 63 6C 61 73 73 3B 1D 40 01 96 3B 14 69 1A 3A 09 40 61 72 67 30 3A 0D 40
                                        ^^
                                        first non-ASCII byte (2)
73 6F 75 72 63 65 73 6F 3A 08 53 65 74 06 3A 0A 40 68 61 73 68 7B 00 3A 0D 40 73 75
62 6A 65 63 74 30 3B 1D 40 01 96 3B 14 69 1A 3B 1D 40 01 96 3B 14 69 1A 3B 14 69 1A
3A 0B 40 73 70 6C 61 74 30 3B 14 69 06 3A 0A 40 61 72 67 73 5B 00 3B 14 69 06

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.

Dmitry


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bug18610_crash.txt --]
[-- Type: text/plain; charset=UTF-8; name="bug18610_crash.txt", Size: 194 bytes --]

;\x19[\ao:^[Sass::Selector::Parent\a:\x0e@filename"\0;\x14i\x1ao:^[Sass::Selector::Pseudo
;\v[\x06"
hover;\x12:
class;\x1d@\x01–;\x14i\x1a:	@arg0:\r@sourceso:\bSet\x06:
@hash{\0:\r@subject0;\x1d@\x01–;\x14i\x1a;\x1d@\x01–;\x14i\x1a;\x14i\x1a:\v@splat0;\x14i\x06:
@args[\0;\x14i\x06