From: "Richard L.F. van Paasen" 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.