Date: Fri, 29 Jun 2001 12:05:37 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT ZAHAV DOT NET DOT IL
To: djgpp AT delorie DOT com
Message-Id: <1858-Fri29Jun2001120536+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
In-reply-to: <3b3c1335.263844384@news.primus.ca> (invalid@erehwon.invalid)
Subject: Re: CWSDPMI registers/symify [was Re: Peculiar behavior of program.]
References: <3b3b4948 DOT 212143163 AT news DOT primus DOT ca> <3405-Thu28Jun2001193951+0300-eliz AT is DOT elta DOT co DOT il> <3b3be8da DOT 252999345 AT news DOT primus DOT ca> <3b3bc6f7 DOT sandmann AT clio DOT rice DOT edu> <3b3c1335 DOT 263844384 AT news DOT primus DOT ca>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: invalid AT erehwon DOT invalid (Graaagh the Mighty)
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 29 Jun 2001 05:37:18 GMT
> 
> On Fri, 29 Jun 2001 00:08:23, "Charles Sandmann"
> <sandmann AT clio DOT rice DOT edu> sat on a tribble, which squeaked:
> 
> >When this happens, I recommend setting the stack space with stubedit 
> >huge (like 1/2 your memory) and try again.  Still crash?
> >Probably in some interrupt handler or something.
> 
> I don't mess with interrupt handlers.

Yes, you do: every DJGPP program installs a handler for the hardware
keyboard interrupt in the startup code.  It also installs a handler
for Int 75h, the FPU interrupt.

> As for stack space, isn't there a stack fault signal and presumably
> something to trigger it as appropriate?

Yes, but since the stack is really just a part of the DS segment, and
SS is loaded with the same selector as DS, you can't have this signal
when the stack overflows, because the protection mechanism cannot
detect it.

> >The "pretty" exception handler which does tracebacks, etc is in the DJGPP
> >code.
> 
> Maybe it should be moved. Or maybe, at least, symify can be modified
> to be able to handle oddball CWSDPMI deaths. Or something. A few raw
> hex numbers are thin gruel for the debugger indeed these days.

Just use the EIP CWSDPMI prints; it's a starting point for debugging.
(I explained in another message how to get the function name and the
source line given the EIP value).