Error handlers in your OS

inflater · Post by **inflater** » Mon Dec 11, 2006 9:44 am

Hi all,
what kind of critical error-handling do you have in your OS?

Well, I have good old BSOD from Win98.

Just modified to suit the needs.

inflater

AndrewAPrice · Post by **AndrewAPrice** » Mon Dec 11, 2006 11:58 pm

I have a BSOD: Black Screen of Death. It switches to text mode, displays the error, disables all interrupts, and places the system a loop. All exceptions, including divide by 0 are caught by this, which gets annoying annoying when I move the mouse to the top line or left of the screen, because my video driver divides the screensize by their position.

AJ · Post by AJ » Tue Dec 12, 2006 3:18 am

Hi,

My OS has not come very far yet, but at the moment, it dumps a physical ram map, virtual ram map and the CPU state to COM1 (and optionally, the screen too).

I have VPC set up to dump it's COM port to a file, and therefore have a nice history of what went wrong

.

Cheers,
Adam

Ready4Dis · Post by **Ready4Dis** » Tue Dec 12, 2006 5:01 am

I haven't gotten any sort of exception handling for much, just displays what happened and keeps on chugging if it wasn't critical, if it was, it pretty much just resets

. I'll work on that more when I get my new memory management stuff done. I will probably implement something that kills the offending process and just display an error message saying what exception it caused and why it was closed.

Steve the Pirate · Post by **Steve the Pirate** » Fri Dec 15, 2006 8:55 am

My OS has a Red screen of death. It just prints what the error was and tells the user to restart the PC.

-Stephen

AndrewAPrice · Post by **AndrewAPrice** » Fri Dec 15, 2006 5:15 pm

AJ wrote: I have VPC set up to dump it's COM port to a file, and therefore have a nice history of what went wrong .

You just inspired me to get a similar thing running under QEMU. Outputting to a COM port may help me to dump kernel messages while working under VESA.

spix · Post by **spix** » Sun Dec 17, 2006 6:00 am

I have this interactive debugger type thing, it doesn't work very well, but the idea is it lets you analyze the stack, contents of memory and so on.

I haven't been motivated to fix it as most of my crashes these days are either in userspace, or some error that doesn't fiire an exception.

JoeKayzA · Post by **JoeKayzA** » Fri Dec 22, 2006 5:14 am

ATM my OS just displays a message in textmode and a register dump, this is for all unhandled exceptions (including unhandled pagefaults), but I do most error analysis using bochs' debugger. (currently my OS has not yet left the bochs)

I'm planning to implement a simple gdb stub as soon as possible, however, using a com port as transport. I hope this isn't getting too difficult...

cheers
Joe

AJ · Post by AJ » Fri Dec 22, 2006 5:42 am

MessiahAndrw wrote:
AJ wrote: I have VPC set up to dump it's COM port to a file, and therefore have a nice history of what went wrong .
You just inspired me to get a similar thing running under QEMU. Outputting to a COM port may help me to dump kernel messages while working under VESA.

I'm glad I inspired someone - and so soon in to my own os's dev process too

I would strongly recommend anyone setting up a similar system though - if DEBUG is defined, my printf function also outputs to the com port. You can register and memory dump at any time you like. I implemented this when I got fed up of the screen scrolling all the time and was pleasantly surprised to find that COM output is even easier than screen output!

Adam

Dex · Post by **Dex** » Fri Dec 22, 2006 10:58 am

I can dump debug info to com port etc.
But in the last 4 years of of Dev a OS, i have not found a error, that can not be found with a simple :

Code: Select all

mov   byte [es:0xB809E], "1"
;some code
mov   byte [es:0xB809E], "2"
;some code
mov   byte [es:0xB809E], "3"
;some code
mov   byte [es:0xB809E], "4"
;some code
mov   byte [es:0xB809E], "5"
;some code

But it maybe differant with other OS designs.

Tyler · Post by **Tyler** » Fri Dec 22, 2006 11:28 am

Dex wrote:I can dump debug info to com port etc.
But in the last 4 years of of Dev a OS, i have not found a error, that can not be found with a simple :
Code: Select all
mov   byte [es:0xB809E], "1"
;some code
mov   byte [es:0xB809E], "2"
;some code
mov   byte [es:0xB809E], "3"
;some code
mov   byte [es:0xB809E], "4"
;some code
mov   byte [es:0xB809E], "5"
;some code
But it maybe differant with other OS designs.

Not very useful when the system double faults and your not there to understand it though is it

I still print dots to see which bits of my code get executed before dieing... but i do have a kernel debugging console if i need to check something specific.

earlz · Post by **earlz** » Mon Dec 25, 2006 10:53 pm

Currently in my old OS(I'm restarting it and only at gdt) I just do a printf saying what the interrupt is..

JackScott · Post by **JackScott** » Tue Dec 26, 2006 5:20 am

COM1 provides transport to a host computer (running Hyperterminal

). Debug messages get output constantly (everytime ANYTHING happens), as well as the CPU state for an exception.

Later on I'm hoping to implement an interactive debugging shell via an ANSI serial terminal, so I can get memory maps, request kernel memory dumps, etc. Note that COM1 isn't used for anything other debugging. The design of my OS means the user can't see COM1 (or any other hardware, directly).

inflater · Post by **inflater** » Thu Dec 28, 2006 2:56 pm

Wow, I am confused why everyone is using serial port for exception-handling or debugging... Maybe that is the easier solution to handle these things?

inflater

urxae · Post by **urxae** » Thu Dec 28, 2006 4:02 pm

inflater wrote:Wow, I am confused why everyone is using serial port for exception-handling or debugging... Maybe that is the easier solution to handle these things?

Well, it has a pretty simple interface, doesn't require any other drivers to work, and is easily written to file or viewed from most emulators...
And it works for real computers as well, of course. All you should need is a null modem and an extra computer to connect it to.