When your OS goes crazy - Screenshots
-
- Posts: 1
- Joined: Tue Feb 25, 2020 1:58 pm
- Libera.chat IRC: SaulloSilva
Re: When your OS goes crazy - Screenshots
Something about this tells me I didn't set up the terminal correctly
- yuukidesu9
- Posts: 12
- Joined: Wed Nov 11, 2020 4:27 pm
Re: When your OS goes crazy - Screenshots
I think the last two letters from thatbgg wrote:Something about this tells me I didn't set up the terminal correctly
Code: Select all
"w ft"
-
- Member
- Posts: 70
- Joined: Tue Jul 14, 2020 4:01 am
- Libera.chat IRC: clementttttttttt
Re: When your OS goes crazy - Screenshots
NetDOS-32 (again) completely freaks out while testing multitasking.
Re: When your OS goes crazy - Screenshots
While fixing a bunch of technical debt i've accumulated in the 32 bit version of the kernel.
Re: When your OS goes crazy - Screenshots
the font looks soo gewd.
Re: When your OS goes crazy - Screenshots
Lol thanks, its hand-drawn with bitmasks actually so I didn't expect it to look wellzaval wrote:the font looks soo gewd.
- AndrewAPrice
- Member
- Posts: 2297
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: When your OS goes crazy - Screenshots
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.
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:
Code: Select all
mov rsp, interrupt_stack_top
Code: Select all
mov rsp, [interrupt_stack_top]
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.
My OS is Perception.
Re: When your OS goes crazy - Screenshots
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
Good to see that I'm not the only one who has such problems occasionally.
Greetings
Peter
Re: When your OS goes crazy - Screenshots
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.
- CorruptedByCPU
- Member
- Posts: 76
- Joined: Tue Feb 11, 2014 4:59 pm
Re: When your OS goes crazy - Screenshots
I am rebuilding the window display system with transparency support, so far I'm doing fine
https://blackdev.org/ - system programming, my own 64 bit kernel and software.
- AndrewAPrice
- Member
- Posts: 2297
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: When your OS goes crazy - Screenshots
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.
My OS is Perception.
Re: When your OS goes crazy - Screenshots
I recommend guard pages. That way, you will notice if someone exceeds the limit. But yeah, 4kB is a bit tight.AndrewAPrice wrote:The cause of my problems: stack overflows. Turns out, 4KB isn't big enough for everybody.
Carpe diem!
- AndrewAPrice
- Member
- Posts: 2297
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: When your OS goes crazy - Screenshots
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.
First attempt for my window manager (which is in userland) to compose the screen using a buffer from a different process.
My OS is Perception.