Visual bugs when scrolling graphical terminal

[austanss]

I have attempted to implement terminal scroll, to no luck.

This is the output I get:
https://cdn.discordapp.com/attachments/ ... -07-37.mp4

This is the source file in question:
https://github.com/microNET-OS/microCOR ... rminal.cxx

I'm rather stumped at this point.

[austanss]

Also, I previously posted a thread on this topic. I suffered some minor data loss, and I no longer have the scrolling code.

[austanss]

OK I since fixed part of the issue, but now there is a different visual bug.

New footage: https://cdn.discordapp.com/attachments/ ... -08-48.mp4

I pushed my changes to github.

[eekee]

OK I since fixed part of the issue, but now there is a different visual bug.

New footage: https://cdn.discordapp.com/attachments/ ... -08-48.mp4

This looks like the display mode changes when it starts scrolling, possibly twice. Could the memcopy be accidentally writing into a VGA control register?

I remember a virtual desktop driver for the Atari ST which copied beyond the end of screen memory; probably an off-by-1 error. Since the screen was at the top of RAM and the ST halted with a bus error if you tried to write beyond the 4MB boundary, the virtual desktop driver worked just fine unless you'd upgraded your ST to 4MB.

[austanss]

That doesn't seem to be the issue.

I changed the memcpy to be so short of it's goal it was visible on screen, and so far ahead of the start the colors were distorted, and it still yielded the same result.

[austanss]

The buffer is proper, it works fine. I can save the screen to the buffer, and restore it properly.

When I scroll the screen via re-rendering the text buffer, it only works when writing directly to screen. If I try to write it to a buffer, that's when it gets hairy.

The only difference between my render_entry_at and render_entry_at_buffer is that one of them writes to the screen, and the other one writes to the buffer. Nothing else changes. The exact same. Meld re-affirms this.

I can't explain this UB.

[neon]

Hi,

Looks like memory corruption to me. What you should be doing is single stepping the assembly. Do not make assumptions about the code nor its running environment when it does not function as expected. Since execution does not appear to end, it may also be stack related or running garbage code. I'd bet the function doesn't return to where you expect it does.

With that said, I took this from your render_entry_at. If your code often has code like this, you are corrupting the stack in more then one location. The last index here is not 64 and the first index is 0. Check your code and be very careful when filling buffers or you can get unexpected behavior.

Code: Select all

uint8_t bits[64];
for (uint8_t i = 1; i <= 64; i++) {
	bits[i] = util::get_bit(font_selector, i);
}

"it works fine" -- I said that about a file written a few years ago and just yesterday while testing an unrelated program is when I find a bug while viewing its object code. Oh, the code worked fine -- but it still had the bug and I wonder how it worked in the first place. You may be surprised how often claiming something is correct turns out not to be true. Working code is often times not Correct code.

[austanss]

I set breakpoints in the code but they are just being passed.

[neon]

Hi,

The code posted above would write one past the end of the array (thus corrupting the byte allocated after, if any.) Since the array is allocated on the stack, this can effect other variables. Please let us know that you have corrected this and all other instances of this bug as it can result in undefined behavior. Array indices start at 0 and end at last_element - 1.

[austanss]

Yes, I fixed that particular issue. I do believe this resolves an intermittent bug with garbage pixels in my character fonts, but that bug is unrelated.

[austanss]

OK, issue resolved.

I was applying fixes, but my build system was not updating the kernel.