Weird exception 13

[pini]

I'm writing a microkernel. For now, I have a program that only increments a register and sends the value to the output program via a kernel message.
The output program reads the value and prints it out.

In bochs, everything works fine, but on some (2 on 4) real computer, I get a exception 13 (General Protection) after some time (not the same delay at each test). There are many reasons for this exception to be raised and I can't check them all.

I would like to know if some of you already had troubles like this and how you get it to work.

[Brendan]

Hi,

I would like to know if some of you already had troubles like this and how you get it to work.

Sure - everyone gets a similar bug sooner or later...

The first thing I'd do is try to figure out why my kernel's general protection fault handler isn't showing me a decent register dump.

Then I'd use the EIP from this register dump to work out where the code is crashing, and the other information in the register dump to figure out why...


Cheers,

Brendan

[distantvoices]

As Brendan says: I'd put a decent register-dump function to my kernel and have it dump registers on say exception 13.

Then, to take it further, try out "objdump -d >yourkernelimagr.bin>kernel.txt<"

This gives you a nifty disassembly. You can trace back the EIP to the actual function in which the crash happens. Then you can go on and stuff this function with debugging printf's - maybe a pointer goes haywire or you simply overwrite something crucial.

One Hint I canna give seldom enough: Zero page dir and page tables before filling in values. You gonna save yourself a lot of hassle. - this only applies if you are using paging.

[pini]

I still don't known why I got a general protection fault, but I found out why my output program was stopping : there was a dead lock, because the "lock" function was interrupted by irq0. Now, it is in a critical section and everything goes well.

huhu, it's not the first time a bug disappears before I found it out ;D

[distantvoices]

Hehe. Cool. Just watch it for a while and stress test it.

I *assume*, that int0 interfering with the "lock" caused some overflow. maybe stack was sent to nowhere due to restless recursive calls of one and the same function - and the cpu decided not to trigger a stack fault but a GPF.

Stay safe.

[IRBMe]

For futures reference, if you use bochsdbg (the debug version) then when you get a fault like that, you can look at the output (if you configured it to dump output) or go into debug mode. The output alone will give you important information such as a register dump. debug mode will let you examine the current state of the CPU, registers, tables and so on, and let you see which instruction caused the fault. Very useful stuff

[pini]

@IRBMe: already using bochs debugging features