🚀 go-pugleaf

In article <14110.2ad025c5@ohstpy.mps.ohio-state.edu>, colovas@ohstpy.mps.ohio-state.edu writes:
>  I have been running up against a bunch of general protection faults while
> trying to use the Borland C++ 3.0 compiler. after trying a number of things to
> correct this problem, all suddested by borland in the CIS forum, I have
> decided to come here. The latest one looks like this:
>
> Exception 13: general protection fault at 024f:0A81 error code 01DC

This is the code segment and offset where    ^^^^^^^             ^^^^
the error occurred. If you have a debugger                       |
or a symbol map, this will let you look at                       |
the instruction causing the problem.                             |
                                                                 |
This is the selector you were trying to load which caused the   -'
interrupt 13 in the first place. Either the 1DC selector doesn't
exist in the LDT or GDT, but somehow your linker thought it existed,
or you're trying to:

	Execute a non executable segment
	Load SS with a non-writable descriptor
	Load DS,ES,FS,GS with an executable but non-readable segment
	Switch to a busy task
	Violate privilege rules

> ax=0032,bx=7020,cx=0000,dx=0D1F,di=0000,si=0002
> ds=05BF limit=FFFF segment# 004C c:\borlandc\bin\bc.exe
> es=0CD7 limit=07FF segment#
> cs=024F limit=0B60 segment# 0015 c:\...\bc.exe
> ss=05BF limit=FFFF segment# 004C c:\...\bc.exe
> Error Code 01DC limit= 092F segment# 
> 
> Unhandled Exception 000D at 029F 0A81 ErrCode 01DC
==============================^^^^= 24F ???

> Memory allocation error
> cannot load command system halted
> --------------------------------------------
> This is not the first one. The thing is,it runs perfectly fine on my 386 w/387
> system at home, so what gives with this? (This is a 486. Both are 33Mhz
> machines, too) borland is the only thing that gives me headaches. Can anybody
> help me out here? any tidbits would be greatly appreciated.

This part is really strange. Either there is something dynamic in your code
that is somehow wiping out part of your LDT and/or GDT making selectors invalid
or you're not doing something the same (i.e. linking, compiling, etc) on both
computers. Or maybe since this is a 486, you're having a cache problem.

The easiest things to mess up are the segment attributes in the linker/builder.
Make sure you've got execute and read/write settings where appropriate. I've
never used Borland's tools, so I can't really help you on this part. If you
narrow it down to a data access problem or a transfer of control, that would
greatly reduce the possible options.

The only thing I noticed in your dump was that all the selectors currently
loaded are running at privilege level 3 (you can tell because a selector is,
from left to right, 13 bits of index, 1 bit of table (1 == LDT), and 2 bits
of Requested Privilege Level). Selector 1DC has an RPL of 0 which is the
highest privilege level. You can only access higher privilege levels by going
through a call gate. If you can specify the privilege levels in your
linker/builder, you may want to make everything 0 and see if this fixes the
problem.

To really track this thing down, you must find out what instruction caused the
int 13. Was it a transfer of control (task switch, call gate) or a data read
or write? Next, it would be real useful to be able to look at the descriptor
tables. Is the 1DC selector valid before execution begins? Is it still valid
after the int 13? What are the attributes of the segment that 1DC represents?

		Mark