OSDev.org

Try to load ELF file

Something about this tells me I didn't set up the terminal correctly

bgg wrote:Something about this tells me I didn't set up the terminal correctly

I think the last two letters from that part are swapped

NetDOS-32 (again) completely freaks out while testing multitasking.

While fixing a bunch of technical debt i've accumulated in the 32 bit version of the kernel.

the font looks soo gewd.

zaval wrote:the font looks soo gewd.

Lol thanks, its hand-drawn with bitmasks actually so I didn't expect it to look well

Not really a screenshot, but my kernel was acting very strangly and I wasted a lot of time on debugging it.

I had a very strange heisenbug where local variables in my kernel were being overritten, but commenting out random code or adding extra debugging code either stopped it or made it modify other random variables!!

I was using the QEMU monitor and halting the world and inspecting the memory location of the variables that should not have modified, that they started looking suspiciously like addresses in my kernel address range. They lined up with addresses in my disassembled kernel (in kind of a reverse stack trace of functions that would have called each other.) I printed rsp in the QEMU monitor and it was pointing into my kernel's BSS section!

I discovered this in my interrupt handler: Instead of: I was setting the stack to the location of the variable 'interrupt_stack_top', rather than the address that the variable 'interrupt_stack_top' was pointing to.

The reason it went undetected was because the linker had been putting 'interrupt_stack_top' at the very start of my BSS section, and BSS is page aligned, so there was a little bit of empty padding and it was never an issue. But, some new code added global variables before 'interrupt_stack_top', and that's when I noticed my bug.

Ha, I didn't know the term "Heisenbug". I had indeed bugs that seem to disappear when trying to isolate them. That was quite puzzling every time it happened. Then you normally have done something wrong where you were sure to do it right. So you have to question what you view as a safe assumption.

Good to see that I'm not the only one who has such problems occasionally.

Greetings
Peter

More of an "OS not going crazy when it should" story. My kernel doesn't do much yet, it's just a learning project. But still, it's 64-bit, paging, protections, preemptive multitasking, etc. I recently implemented fork() in a fairly simplistic way, and after verifying it worked, I figured why not stress test it, so I made it recursively re-fork ad infinitum, and it was juggling something like 2,000 active processes when I finally stopped it. I guess that's a good sign.

I am rebuilding the window display system with transparency support, so far I'm doing fine

I was seeing random crashes in my userspace window manager. The stack trace was showing seemingly random locations for the crashes. For example:

• std::find was page faulting when my map was global and my key was on the stack.
• My linked list was pointing to phantom elements, even though I printed the values of every element I was adding to the list.

The cause of my problems: stack overflows. Turns out, 4KB isn't big enough for everybody.

AndrewAPrice wrote:The cause of my problems: stack overflows. Turns out, 4KB isn't big enough for everybody.

I recommend guard pages. That way, you will notice if someone exceeds the limit. But yeah, 4kB is a bit tight.

First attempt to draw widgets to the screen.

First attempt for my window manager (which is in userland) to compose the screen using a buffer from a different process.