Strange crash when paging down a particular file in a text editor

[jes]

I'm using an RC2014 VGA Serial Console in a homemade CPU, and I am encountering a strange crash when trying to edit a particular text file. Here's a video demonstrating the problem: https://www.youtube.com/watch?v=OKDQznJkS2M

This happens reliably every single time I try to page down this file by 2 pages. Steps to reproduce (although nobody but me has this computer) are:

1. open hamurabi.sl in kilo (it only works for hamurabi.sl, and it only works in the text editor - catting it to the screen doesn't cause any problem - I haven't yet investigated what specifically about this source file is causing the problem).
2. scroll down twice (Ctrl-D, Ctrl-D)
3. the VGA console will crash, and the screen will probably turn off (occasionally it shows a green-and-yellow pattern instead of turning off).

I wonder how we would go about debugging this? I think a first step would be to capture the exact bytes that are transmitted and replay them using a USB serial cable and see if it still crashes it - that would rule out some hardware-specific timing problem and would allow others to reproduce the problem. I'll work on doing that.

[jes]

This happens on both the RC2014-compatible board and on a standalone one that I don't think you sell any more, that I bought online from a chap in Gibraltar, which I think rules out any possibility that I have a faulty board.

[jes]

From watching the video back frame-by-frame it appears to get stuck on the first line in the file that is more than 80 characters wide (it's 81), which seems like it could be a good clue. The editor is meant to stop the line at 80, but even if it doesn't I don't think the terminal should crash every time it has to line wrap.

[jes]

In this file: https://github.com/maccasoft/propeller-vt100-terminal/blob/master/com.serial.terminal.spin#L307

For "other" it only writes into byte[line][size] if size < maxline, but for NL,LF it can write to byte[line][size] even if size == maxline. This seems like it could be the problem. I think my editor is writing a newline 1 character past the end of the line, which is causing a buffer overflow in the terminal?

[jes]

I tried making a new file and typing a line that is as wide as the screen and it caused the terminal to crash, so I'm pretty sure this is the problem, but I don't quite see why overflowing a line, other than the bottom one, causes a crash rather than just overwriting the start of the next line.

I'm also surprised that this has never been observed before - I wonder if my editor also has an off-by-1 error on the line width which is triggering this bug in a way that most wouldn't.

[jes]

I can't actually find anything that calls ReadLine, so maybe that is unused vestigial code and isn't the source of the problem after all?

[maccasoft]

The terminal firmware doesn't provide any editing capability, it only decodes the ANSI escape codes.
My guess is that the editor sends a code that is not interpreted correctly by the firmware causing a write to a location outside the screen buffer. Since it is reproducible, can you attach the minmal files needed ? I think the kilo editor executable and the source file you are editing ? I'll try to reproduce here and capture the code stream to see if there are weird escape codes.

[jes]

kilo-hamurabi.log
I don't think the executable will be much use to you - this isn't a Z80 machine, it's a completely homebrew CPU design.

I've attached a capture of the bytes output in a session booting up, starting the editor, and paging down 3 times.

I believe the line "IN YEAR %u, %u PEOPLE STARVED, %u CAME TO THE CITY" is the one that crashes the terminal.

[jes]

I deleted all of the lines apart from "IN YEAR %u" and cat'd it to the VGA Serial PCB via an FTDI cable, and it still crashes. It does not crash if I delete the "ESC [ K" at the end of the line.

So I'd say the problem seems to be caused by an "ESC [ K" (clear to end of line) while the cursor is already at the end of the line.

[jes]

I think the implementation of "ESC [ K" is here:
https://github.com/maccasoft/propeller-vt100-terminal/blob/master/vt100.spin#L1178 but I'm not smart enough to see if there's an obvious error.

[jes]

I think the problem is in :el0: t3 gets set to #scrn_columns - x, and then there is djnz t3, but if x == #scrn_columns then this will decrement t3 to -1 and then overwrite almost all of memory.

It's not quite as simple as that because there are some -2 lying around, but I think it's roughly that?

[maccasoft]

Good catch, the problem was that. I have added the zero check and now it should work correctly.
I'm attaching the updated binary, please check if it works for you, then I'll update the source.

If you want to test with a terminal program, the sequence ESC[1;80H-ESC[K should trigger the crash.

rc2014_terminal_720x400_usb.zip

[jes]

Thanks! I've never written a binary to this before and don't have a Prop-Plug, but I'm going to follow these instructions for writing to the EEPROM: http://www.learningaboutelectronics.com/Articles/24LC256-EEPROM-circuit-with-an-arduino.php and hopefully I'll succeed.

[jes]

Perfect, that did the trick, thanks again!

[jes]

I'd be keen to see the source as I'd like to apply it to https://github.com/MorfeoMatrixx/propeller-vt100-terminal/ which adds dynamic baud rate selection.

[jes]

Great stuff, thanks Marco! 👍