When your OS goes crazy - Screenshots
-
- Member
- Posts: 36
- Joined: Wed Sep 01, 2010 3:54 pm
Re: When your OS goes crazy - Screenshots
This is mine while I try to figure out why I'm getting a page fault when reading a memory mapped io device.
-
- Member
- Posts: 34
- Joined: Sat Sep 07, 2019 5:17 pm
- Libera.chat IRC: Superleaf1995
Re: When your OS goes crazy - Screenshots
This happened when i tried to load a .COM without properly setting segments
Re: When your OS goes crazy - Screenshots
Image decoder faults are a bit cliché, but since I've finally gotten around to working on a PNG decoder here's a WIP screenshot where things went a bit wrong:
Re: When your OS goes crazy - Screenshots
Reminds me of a friend's real-mode assembly-language unix. A program could be loaded wrong depending on its size, of all things. He suspected a bug in the FAT12 driver, but it was already an abandoned project by that point. It was only written to settle an argument, and my friend was too inexperienced to code assembler well.SuperLeaf1995 wrote:This happened when i tried to load a .COM without properly setting segments
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
Re: When your OS goes crazy - Screenshots
Most kernel in this topic
Re: When your OS goes crazy - Screenshots
I'm a little concerned about Bart's state of mind...
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
-
- Member
- Posts: 44
- Joined: Fri Sep 09, 2016 5:52 pm
- Location: Australia
- Contact:
Re: When your OS goes crazy - Screenshots
This isn't what is supposed to happen on loading a DOOM save
Re: When your OS goes crazy - Screenshots
A classic
- Attachments
-
- z5IH3e8.png (7.22 KiB) Viewed 33215 times
Last edited by Haoud on Fri Jul 31, 2020 1:25 pm, edited 1 time in total.
Re: When your OS goes crazy - Screenshots
I've upgraded my build environment to the latest, and strange things started to appear...
With gcc, it doesn't matter if I compile for AArch64 or x86_64, with or without optimizations. Everything works (at this point all processes must block waiting for messages).
With CLang, everything works as expected for AArch64, but for x86_64 I get the following error. The interesting thing is, I don't even tried to mount root file system yet (FS task should just block too). Also, the backtrace looks pretty funky: "seterr" just sets a thread-local variable, it calls no function at all, definitely not "pipe_read", and there's no way that "mq_recv" called "main" either... Okay, there's no other solution, it's time for a through debug!
Cheers,
bzt
With gcc, it doesn't matter if I compile for AArch64 or x86_64, with or without optimizations. Everything works (at this point all processes must block waiting for messages).
With CLang, everything works as expected for AArch64, but for x86_64 I get the following error. The interesting thing is, I don't even tried to mount root file system yet (FS task should just block too). Also, the backtrace looks pretty funky: "seterr" just sets a thread-local variable, it calls no function at all, definitely not "pipe_read", and there's no way that "mq_recv" called "main" either... Okay, there's no other solution, it's time for a through debug!
Cheers,
bzt
Re: When your OS goes crazy - Screenshots
This is a neat looking kernel debugger
Re: When your OS goes crazy - Screenshots
Quite an epic debugger you got there mate. Is it worth coding? Is it better than plain old Bochs?bzt wrote: Okay, there's no other solution, it's time for a through debug!
Re: When your OS goes crazy - Screenshots
@Monax, @jlxip: thanks!
Otherwise writing a debugger is not a big deal. Here's a minimal one, only ca. 300 SLoC. It is for AArch64, but the code would be pretty much the same for x86 (except for the disassembler). This one is MIT licensed.
The code for the debugger you see on the screenshot is here. It's more complex, the common part being more than 1000 SLoC. The architecture specific parts are in their corresponding directories (supports x86_64 and AArch64). This is not a free software, licensed under CC-by-nc-sa.
As for the disassembler, it's available as a separate project, udisasm (for AArch64, I haven't migrated the x86 disassembler to this new format yet, but I'm going to. Any help would be appreciated ). The udisasm is licensed interestingly, the instruction tables and the generator script is licensed under GPL (so it's free, but copyleft), while the generated C headers are MIT licensed (so you can include the generated disassembler code in any project, even in proprietary ones).
Cheers,
bzt
Well, I needed a debugger that I can run on real hardware using only minicom on the other side. I was thinking about implementing gdb-server, but that protocol is just too dumb for what I need. So for me it wasn't a question of worth it, but it was a necessity, a must have.jlxip wrote:Quite an epic debugger you got there mate. Is it worth coding? Is it better than plain old Bochs?
Otherwise writing a debugger is not a big deal. Here's a minimal one, only ca. 300 SLoC. It is for AArch64, but the code would be pretty much the same for x86 (except for the disassembler). This one is MIT licensed.
The code for the debugger you see on the screenshot is here. It's more complex, the common part being more than 1000 SLoC. The architecture specific parts are in their corresponding directories (supports x86_64 and AArch64). This is not a free software, licensed under CC-by-nc-sa.
As for the disassembler, it's available as a separate project, udisasm (for AArch64, I haven't migrated the x86 disassembler to this new format yet, but I'm going to. Any help would be appreciated ). The udisasm is licensed interestingly, the instruction tables and the generator script is licensed under GPL (so it's free, but copyleft), while the generated C headers are MIT licensed (so you can include the generated disassembler code in any project, even in proprietary ones).
Cheers,
bzt
Re: When your OS goes crazy - Screenshots
So what should have been my page table ended up in the screen buffer.
If that's even what happen.
But given the repeating graphic pattern in the top of the screen, and that the setup of the page table is pretty much all that's happens in this test,
my guess is that my page table ended up in the screen buffer.
If that's even what happen.
But given the repeating graphic pattern in the top of the screen, and that the setup of the page table is pretty much all that's happens in this test,
my guess is that my page table ended up in the screen buffer.
- Attachments
-
- Page table in screen buffer
- Screenshot at 2020-07-28 20-47-33.png (4.05 KiB) Viewed 33278 times
-
- Member
- Posts: 70
- Joined: Tue Jul 14, 2020 4:01 am
- Libera.chat IRC: clementttttttttt