General Protection Fault / Exception 0D / How do I debug?

[Mateusz Viste]

Hi list,

I am working in my spare time on a little project written in Turbo C,
and I got somewhat stuck with a problem I don't really know how to solve.

Long story short - my program is generating an "Exception 0D" (as
reported by the JemmEx memory manager) and freezes the whole system.

I have very little experience when it comes to such low level
programming - and I have no clue how I could figure out what's happening
exactly...

What tried:
a) staring at the code for hours
and
b) filling the code with plenty of printf() to see where it goes fishy

a) didn't bring any result. with b), at least I know what portion of
code trigger the problem, but I have doubts that the portion of code
that triggers the exception is actually the one that is buggy, since it
only calls outportb() in a short loop.

So here's the question: how did people investigate such troubles back in
good old days?

Mateusz

[JJ]

Make sure all 16/32 bit memory accesses don't go beyond offset 0xFFFF.
For example, reading a 16-bit value from memory at offset 0xFFFF, or read
32-bit value from offset 0xFFFD.

[Johann Klammer]

By using an interactive debugger.
If you don't have one you could try setting a handler for the exception,
figure out the value of EIP and from that the line number in your source
file via the debug information(No, you don't want to do that). The 0D
tells you what kind of fault it was. Maybe a protection fault.. not sure
as I haven't read in those intel manuals for quite a while. You can find
the pdfs on the net.

IA-32 Intel� Architecture
Software Developer�s
Manual

There's three volumes...
You don't want to read it all...

If the bug is not obvious, it's probably an allocation thing. Check the
lifetimes of all your allocations...

[Rod Pemberton]

This is quicker than the AMD or Intel manuals. See Exception 0Dh here:
http://support.microsoft.com/kb/117389

You can probably confirm or eliminate your code as the problem by
trying different EMS memory managers, e.g., MS-DOS EMM386, FreeDOS
EMM386. If they don't fail, your code is likely correct.

If they don't fail and the code is not correct (unknowable at this point),
it's almost correct. E.g., I found that many DPMI hosts would work with
some of my DPMI code, but one wouldn't. I was missing one step which
that DPMI host required.

I tend to use the print statement method of debugging. It usually
leads directly to the exact spot of failure in C for normal C. But,
when dealing with DOS, BIOS, XMS, EMS, DPMI, or VCPI etc, it could be
something else in your code causing code other than yours to fail.
In that case, your code should still fail if the port loop is commented
out. If it still fails, comment out or "#if 0" "#endif" out more and
more code until you only have only the code causing the failure. If
commenting out the port loop eliminates the failure, it's something to
do with the loop. It could be the code, or it could be through an
interrupt that is being triggered. You can also try adding a CLI and
STI instruction around the loop code. In C, these will sometimes be
available as "enable" or "disable" perhaps with underscores.


Rod Pemberton

[Mateusz Viste]

Hi all,

Thanks for all your pointers.

What I understood is that there is no magic tool to debug such low-level
problems, and one have to stick with printf()ing debug notices all over
the code to locate more or less where the problem happens, possibly
combining it with cutting out as much code.

That's okay, I wasn't expecting miracles :) At least I know that I have
to continue investigating the hard way.

Actually, I did find out what causes the problem. It appears I have two
bugs - in two different parts of my program (and of course these are the
two parts that were totally new stuff to me, so I have no idea how they
should be done 'right'). One is related to my PIT reprogramming leading
to a stack overflow, and the other one triggers a 0D exception when I
call the system's XMS driver. But this goes off-topic. As far as
debugging is concerned, I know what options I should stick to, thanks!

I will prepare new threads about my newly discovered/located problems
though, with some actual code, in case anyone would care to spare a few
minutes with an expert eye on it :)

cheers,
Mateusz

On 07/22/2014 09:11 PM, Mateusz Viste wrote:

[Rod Pemberton]

On Wed, 23 Jul 2014 06:01:22 -0400, Mateusz Viste
<mateusz.viste@localhost> wrote:

> One is related to my PIT reprogramming leading
> to a stack overflow,

There are a few people still on alt.os.development who
have done PIT programming, in varying amounts, including
myself. Or, you could try OSDev (wiki.osdev.org).
They have a bunch of OS (operating system) related
pages and a forum.

> and the other one triggers a 0D exception when I call the system's XMS
> driver.

I've not used XMS directly, except to check for it's
presence. I do use DPMI hosts, which will allocate
memory from XMS when installed.


Rod Pemberton

[Mateusz Viste]

Actually I think I found the culprit - the exception 0D happens only
when I use my XMS routines (that I posted in another thread). Right now
I replaced my XMS mini library with a dumb module that emulates the same
API, but relying on simple malloc/free, and now the application doesn't
trigger any exceptions anymore!

Of course it's not a solution, since using malloc() I can address max.
64K of RAM, which is not enough for my needs, but at least I know what
part of the code I have to blame now :)

cheers,
Mateusz




On 07/22/2014 09:11 PM, Mateusz Viste wrote: