GPF when trying to print in interrupt handler

[sylvarant]

Hi all,
I'm having this weird problem in my very early stage OS, when I'm trying to print a message in in my interrupt handler, but it seems to go crazy on me every time I try to call an interrupt.
It keeps on printing this interrupt message (yes the printing itself works pretty well) saying I'm facing a general protection error.

edit : it's seems I'm not throwing a never ending amount of errors when I decide to print an integer after my print statements, this is very weird

[jal]

I'm having this weird problem

Getting GPFs is one of the most common effects of any problem in an OS, so I wouldn't call it weird on forehand.


JAL

[AJ]

I can't see from the posted source what the problem is, but:

1) Try running your OS in Bochs - this often gives useful information on a GPF.
2) Are you using some kind of local variable to store the ASCII-coded number string and then trying to access the variable from elsewhere? It looks like a stack-alignment type problem could be a possible cause.
3) Are you expecting to be executing code at address 0x392f3020? It looks like this is where VirtualBox thinks EIP is when the error occurs.

Cheers,
Adam

[AJ]

Oh - one other thing. You say you re 'calling' the interrupt. If you are doing this manually (e.g. Int 0x00) and not by deliberately causing an exception (e.g. int x = 1/0), your ISR will be expecting an error code to be pushed, which does not happen if you use the manual method (I think someone else mentioned this in a recent thread...).

Again, if this happens it will cause a stack misalignment with an invalid CS selector and EIP once you IRET.

Cheers,
Adam

[sylvarant]

ok thanks for the replies,
Ok I'll install bochs once I have some time for that, it seems to be a very popular program around here.
I think a stack misalignment could very well be causing the problem, so no more manual calls for me then

[AJ]

Hi,

Ok I'll install bochs once I have some time for that, it seems to be a very popular program around here.

There's a good reason for this. Because Bochs is an emulator rather than a virtualisation suite, it emulates every instruction individually. The debugger is capable of stepping and Bochs can show you the contents of every register on an error. With GPF's, before the register dump it will often tell you why the GPF happened too (for example 'CS beyond GDT limits' or similar gives you a very good idea that a stack misalignment has happened, if it occurs on an IRET).

I think a stack misalignment could very well be causing the problem, so no more manual calls for me then

Just to completely clarify, manual calls (sorry; 'Software Interrupts') are fine as long as the interrupt handler is set up for it, for example software interrupt 0x80. If the handler is designed to handle an exception with an error code, however, manually calling the vector will misalign the stack.

Cheers,
Adam

[JamesM]

ok thanks for the replies,
Ok I'll install bochs once I have some time for that, it seems to be a very popular program around here.
I think a stack misalignment could very well be causing the problem, so no more manual calls for me then

As AJ has said, bochs is an instruction interpreter only. It does not convert chunks (basic blocks) of subject code into target code and execute natively, so it is capable of providing a precise state for any faulting instruction.

Faster translators such as qEmu use basic block translation and so cannot provide a precise state without much effort.