OSDev.org

Implemented some maths functions to my kernel's runtime library because I want cool graphics stuff, so tested out some pixel plotting, and a couple famous line and ellipse drawing algorithms. Everything works but I gave some off parameters and got this! Want to become good with the graphics/mathematical side of things

rwosdev wrote:Implemented some maths functions to my kernel's runtime library because I want cool graphics stuff, so tested out some pixel plotting, and a couple famous line and ellipse drawing algorithms. Everything works but I gave some off parameters and got this! Want to become good with the graphics/mathematical side of things

Well, that looks fine to me, if you goal was to depict a Mobius strip. I gather it wasn't, however.

That's exactly what it's like! No it wasn't the aim!!!

Not even Rust is immune to undefined behaviour.

Don't worry! There are enough smiley faces and hearts to solve this.

MyBSOD

Just working on paging

Not really going crazy, and it's actually expected behavior, but crashing nonetheless. I am currently porting my compiler/VM to my OS to provide a user-mode programming language. Here you can see it come to life.

What happened is the VM crashed because of an unimplemented opcode, which resulted in the VM trying to drop its hosting task. However, my proof-of-concept implementation is running it in the kernel task, which is "immortal" (can't be dropped). The result is that the CPU continues executing garbage and eventually raises an interrupt.

Happened after I pressed CTRL+D (aka, EOF) at my shell prompt

The shell should probably exit if it encounters an EOF - but first I need to figure out why I could only spawn up to PID 999

One of my favorites from a few months back,



Looks like a pretty standard panic screen right? Turns the screen red and print some debug info? The reason that, shall we say, mildly surprised me is that I never programmed it to turn red. In fact, the whole operating system literally has no code to change the color of the screen!

It even got worse from there:



What it turned out to be was that I had screwed up my initial implementation of threading, and was setting the RSP0 value in the TSS to the bottom of the allocated stack region, so the stack was immediately clobbering kernel data. What happened to be right below the stack for the first thread? The default background color applied to all characters printed.

Ran across a few different issues with how I was handling self-delivered signals, so here's a rare look at what a particularly catastrophic failure looks like in my serial log:



(Click for full size)

Working on this....

I wrote the wrong magic numbers to the wrong IO ports

I tracked this down to a missing printf flag handler causing a constant fold to fail while trying to locally build a graphical demo. Wasn't even aware gcc folded stuff like this...

Poor console driver tries to follow 4 "conversations" (CPU cores) at once

Basically it's just saying "Error: drive has no errors."