From:	"Richard L.F. van Paasen" <R DOT L DOT F DOT v DOT Paasen AT stud DOT tue DOT nl>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Infinite number of protection faults
Date:	Sun, 29 Sep 1996 17:00:42 -0700
Organization:	University of Technology Eindhoven
Lines:	119
Message-ID:	<324F0DA9.238C@stud.tue.nl>
Reply-To:	R DOT L DOT F DOT v DOT Paasen AT stud DOT tue DOT nl
NNTP-Posting-Host:	annex1s6.urc.tue.nl
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

SUBJECT: infinite number of protection faults

Hi, 

I recently ported a C++ program (5000 lines) that is written 
with Borland C 3.1 to DJGPP 2.0. It works ok if I execute
the program when it is compiled with the Borland C compiler.

DJGPP was able to compile it too, but when I run the program
(with DPMI host QEMM, Windows 3.1 or CWSDPMI), it generates
protecion faults. This happens in the initalisation phase of
the program, when it is reading some files and creating some 
data structures).

I tried to compile the program with the -g option, to SYMIFY
a coredump, but I can never get to that stage, because the 
program is not stopped. The general protection faults 
(due to a segment violation, SIGSEGV) keep being printed on
screen as if they are generated in an infinite loop! The only
way to stop the program is to reboot the computer.

There is one large source file in the program (over 1000 lines).
This source file is the part of the program that does the 
initialisation where my gen. prot. faults seem to happen.
When I compile it with gcc, and with the 486 and O2 options,
gcc generates a protection error! So I compiled it without those
options, which worked. However, as said, my program generates
protecion faults when it is executed. This happens after a few
seconds, while it is initialising.

--------------------------------------------------------------------
Did anyone experience such a problem before? (infinite number of
protection faults) And how can I track the error (if it is an error,
because with Borland C it didn't crash; the program has been tested
*extensively* ). Does the error reside in DJGPP, or in my source code?
--------------------------------------------------------------------

Here are the starting 4 of thousands of general protection faults,
a copy of the beginning of the trash that is dumped onto my screen:

Exiting due to signal SIGSEGV
General Protection Fault at eip=00033142
eax=0009298b ebx=00092870 ecx=000affb3 edx=000b0000 esi=00092870
edi=000871e0
ebp=00086ef0 esp=00086eec cs=00af ds=00b7 es=00b7 fs=0087 gs=00c7
ss=00b7
Call frame traceback EIPs:
  0x00033142
  0x0002d4f2
  0x0002d580
  0x5c5c5c5c
Exiting due to signal SIGSEGV
General Protection Fault at eip=00032baf
eax=ca8b0c7c ebx=00093000 ecx=00000000 edx=00000000 esi=000337b8
edi=000337d1
ebp=00086e3c esp=00086e34 cs=00af ds=00b7 es=00b7 fs=0087 gs=00c7
ss=00b7
Call frame traceback EIPs:
  0x00032baf
  0x00033c2c
  0x00033d80
  0x00033e09
  0x0009298b
  0x0002d4f2
  0x0002d580
  0x5c5c5c5c
Exiting due to signal SIGSEGV
General Protection Fault at eip=00032baf
eax=ca8b0c7c ebx=00093000 ecx=00000000 edx=00000000 esi=000337b8
edi=000337d1
ebp=00086d84 esp=00086d7c cs=00af ds=00b7 es=00b7 fs=0087 gs=00c7
ss=00b7
Call frame traceback EIPs:
  0x00032baf
  0x00033c2c
  0x00033d80
  0x00033e09
  0xca8b0c7c
  0x00033c2c
  0x00033d80
  0x00033e09
  0x0009298b
  0x0002d4f2
  0x0002d580
  0x0002d4f2
  0x0002d580
Exiting due to signal SIGSEGV
General Protection Fault at eip=00032baf
eax=ca8b0c7c ebx=00093000 ecx=00000000 edx=00000000 esi=000337b8
edi=000337d1
ebp=00086ccc esp=00086cc4 cs=00af ds=00b7 es=00b7 fs=0087 gs=00c7
ss=00b7
Call frame traceback EIPs:
  0x00032baf
  0x00033c2c
  0x00033d80
  0x00033e09
  0xca8b0c7c
  0x00033c2c
  0x00033d80
  0x00033e09
  0xca8b0c7c
  0x00033c2c
  0x00033d80

And so on, the general protection fault seems to appear in an
infinite loop. The only way to stop it is to reboot my computer!
Note the growing "call frame traceback EIPs", the last one is
repeated infinitely.

My computer:
  486 50 MHz, Cyrix
  8 MB ram
  mouse and UNIVBE loaded
  QEMM loaded (also tested with Windows and CWSDPMI)
  virtual memory: 20 MB
  The program needs about 500 KB of memory

Richard van Paasen.

- Raw text -