Live data from Hacker News

Can anyone explain why this crash editors?

news.ycombinator.com

1–10 of 10 posts

Can anyone explain why this crash editors?

#1
I was coding and something happened with atom and I was unable to reopen my project without atom crashing. I deleted my code in notepad and extract this which is causing crashes in Microsoft Word and extreme lag in notepad++ and Atom. Anyone know why this is the case?

PS: This file is only 9mb so it shouldn't be too big for anything to view it

Thanks https://www.dropbox.com/s/ru1qlmi92ky4y53/weirdFile.js?dl=0

Re: Can anyone explain why this crash editors?

#3

Opening this file in a hex editor shows that the file consists of almost all spaces, which I'm assuming are all on one line, making the text editors crash.

Yeah, hexdump shows:

    00000000  ef bb bf 2f 3e c2 a0 0a  20 20 20 20 20 20 20 20
    00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
    *
    00900000  20 20 20 20 20 20 20 20  3c 61
    0090000a

Which means that except for those first 8 bytes and the last two, the whole file is just 0x20 (space in ASCII/UTF-8) repeated ad nauseam.

Re: Can anyone explain why this crash editors?

#4

Opening this file in a hex editor shows that the file consists of almost all spaces, which I'm assuming are all on one line, making the text editors crash.

Yeah, hexdump shows: 00000000 ef bb bf 2f 3e c2 a0 0a 20 20 20 20 20 20 20 20 00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 * 00900000 20 20 20 20 20 20 20 20 3c 61 0090000a Which means that except for those first 8 bytes and the last two, the whole file is just 0x20 (space in ASCII/UTF-8) repeated ad nauseam.

Why would long lines crash editors?

Re: Can anyone explain why this crash editors?

#5
post #4

Earlier quoted context omitted.

Yeah, hexdump shows: 00000000 ef bb bf 2f 3e c2 a0 0a 20 20 20 20 20 20 20 20 00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 * 00900000 20 20 20 20 20 20 20 20 3c 61 0090000a Which means that except for those first 8 bytes and the last two, the whole file is just 0x20 (space in ASCII/UTF-8) repeated ad nauseam.

Why would long lines crash editors?

If the editor has some built in line length limit then exceeding that limit might lead to a crash (depending upon how the editor is coded).

Re: Can anyone explain why this crash editors?

#6
post #4

Earlier quoted context omitted.

Yeah, hexdump shows: 00000000 ef bb bf 2f 3e c2 a0 0a 20 20 20 20 20 20 20 20 00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 * 00900000 20 20 20 20 20 20 20 20 3c 61 0090000a Which means that except for those first 8 bytes and the last two, the whole file is just 0x20 (space in ASCII/UTF-8) repeated ad nauseam.

Why would long lines crash editors?

Well, VIM doesn't crash :) But edge cases in general are where the bugs lurk, and 9MBs of spaces is certainly an edge case. A possible cause might be that they try to render the whole line, try to allocate too much memory, and crash when the allocation fails. Whereas if the file had many lines, they'd probably be smart enough to only render part of it.

Re: Can anyone explain why this crash editors?

#7
post #5
post #4

Earlier quoted context omitted.

Why would long lines crash editors?

If the editor has some built in line length limit then exceeding that limit might lead to a crash (depending upon how the editor is coded).

Right but it looks like (i was able to load it for Atom and Notepad++ but very slow) they perform soft wrap on these long lines

Re: Can anyone explain why this crash editors?

#8
The file opens in a blink of an eye on Linux in both the Joe editor (http://joe-editor.sourceforge.net/) as well as in vi (i.e., it is about about a second or less to open the file in each). So the problem would be that Word, Notepad++, and Atom have trouble with very long lines.

Re: Can anyone explain why this crash editors?

#9
post #7
post #5

Earlier quoted context omitted.

If the editor has some built in line length limit then exceeding that limit might lead to a crash (depending upon how the editor is coded).

Right but it looks like (i was able to load it for Atom and Notepad++ but very slow) they perform soft wrap on these long lines

Which would imply that their soft-wrap algorithm consumes an inordinate amount of time when confronted with a single, 9MB long, line of space characters.