From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: GPF with system() and clock int. Date: Sat, 22 Jul 2000 2:15:38 Organization: Aspen Technology, Inc. Lines: 21 Message-ID: <397903ca.sandmann@clio.rice.edu> References: NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 964252087 2380 10.32.115.107 (22 Jul 2000 07:48:07 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 22 Jul 2000 07:48:07 GMT X-NewsEditor: ED-1.5.8 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > General Protection Fault in RMCB at eip=405a; flags=3046 > eax=01a94c00 ebx=000100a7 ecx=00000015 edx=00016500 esi=000010b6 edi=10000000 > ebp=00000000 esp=00001120 cs=2b ds=33 es=8f fs=0 gs=0 ss=33 error=0000 Okay, lets look at this second failure. Since this is r4, I can see that this EIP=405a is always the failure point. It turns out this is in ivec31x, which is in the return from any dpmi_int call. ECX, ESI and DS confirm the location. ES:EDI looks bogus - we wouldn't put registers back in their space at this address (it's bigger than the limit, so gives the GPF). But we didn't fail on the way into int31, and we don't modify EDI anyplace ... so it looks like this register got smashed someplace. It must have been when we were in dpmisim, since that's the only place interrupts are enabled. I don't know why. Maybe a bug someplace - may be an artifact of the first failure not being cleaned up completely. This tends to indicate the first failure is happening in one of the nested tasks, and then the second failure is happening on the system() return? Try increasing the internal stack size with CWSPARAM. If that doesn't fix it I'm not sure how to fix it without a lot more time than I have to spend looking for the problem.