From:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
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:	<Oa1e5.1929$652 DOT 72004 AT newsc DOT telia DOT net>
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.

- Raw text -