Xref: utzoo comp.lang.c:19842 alt.msdos.programmer:194
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!agate!ucbvax!hplabs!hp-sdd!megatek!zeta!hollen
From: hollen@zeta.megatek.uucp (Dion Hollenbeck)
Newsgroups: comp.lang.c,alt.msdos.programmer
Subject: Re: Help! (Problems with the stack?)
Message-ID: <616@megatek.UUCP>
Date: 11 Jul 89 19:48:25 GMT
References: <2163@wasatch.utah.edu>
Sender: news@megatek.UUCP
Distribution: usa
Lines: 39

From article <2163@wasatch.utah.edu>, by u-tholly@wasatch.utah.edu (Troy Holly):
> Here is the scoop.  I am coding in Microsoft C 5.1, and am using the 
> CodeView debugger.  I have a line of code that passes arguments to
> the tanh() math function, but when I get there, all of the variables
> in the calling routine become undefined, and I get an "M6101 invalid"
> floating point error.  This particular line of code is executed many
> times before (it is in a loop) with no problems.  Using the debugger,
> I have traced every step of the execution, and the variables in the
> calling routine are just fine.  As soon as execution is passed to
> tanh() they become undefined; however, after examining thier memory
> locations, they are still intact.  [...further explanation deleted...]


Not sure if this will solve the problem, but how about going into
the assembly mode of debbuging in Codeview just before you are about
to call the tanh() function?  Put up the register window and watch
as the stack pointer is changed as your arguments are pushed on
the stack.  Just before executing the "call tanh" in assembly,
write down both the stack pointer and stack segment values.  Do a
dump word command at that location and see if the values you should
have pushed on the stack were really pushed there.  Do a step
command and then examine the stack again using the same SS:SP
combo you wrote down.  If nothing is changed, your data is still
OK on the stack.  Check the current value of SS:SP.  SS should have
remained constant.  SP should have been decremented by 2 in the
small and I believe medium model, and by 4 in large and huge models.
(If this info is incorrect, what is definitely correct is that a
NEAR call will decrement SP by 2 and a FAR call will decrement by 4.
I sometimes get confused by the naming of the memory models and which
generates NEAR and FAR code/data references.)  If your SS:SP values
are still reasonable and the data on the stack has not been stepped
on, step through the tanh function and see if it is trying to pick
up the data incorrectly, like maybe BP is being trashed, or incorrectly
initialized in the module preamble.  Hope this is of some help.

	Dion Hollenbeck             (619) 455-5590 x2814
	Megatek Corporation, 9645 Scranton Road, San Diego, CA  92121

        uunet!megatek!hollen       or  hollen@megatek.uucp