u-tholly@wasatch.utah.edu (Troy Holly) (07/11/89)
Have you ever had a piece of code that looses track of the stack? I thought this kind of thing only happened in Fortran. 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. Just before the call to the tanh() function, I call memaval() and stackavail(), and there are 52k and 1k bytes free respectively. At first I thought maybe the problem was a memory allocation error, but the heap is a long ways from the stack and data segments, according to the debugger. My best guess is that the location of the variables in the calling routine are getting lost in the stack. Your best guess has got to be better than mine, so help me out if you can. Thanks in advance, Troy -
aic@s.cc.purdue.edu (George A. Basar) (07/11/89)
In article <2163@wasatch.utah.edu>, u-tholly@wasatch.utah.edu (Troy Holly) writes: > 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 Have you checked your memory model and the lib you are linking with to be sure they match? Could be that you are mixing models and the lib routine expects both selector:offset and you are only pushing offset or selector(incorrect one):offset (in the case where ds != ss)
u-tholly@wasatch.utah.edu (Troy Holly) (07/12/89)
In article <3943@s.cc.purdue.edu> aic@s.cc.purdue.edu (George A. Basar) writes: >In article <2163@wasatch.utah.edu>, u-tholly@wasatch.utah.edu <me> (Troy >Holly) writes: >> 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 > Have you checked your memory model and the lib you are linking >with to be sure they match? Could be that you are mixing models and the >lib routine expects both selector:offset and you are only pushing offset >or selector(incorrect one):offset (in the case where ds != ss) As soon as I sent that message off, I realized that I fotgot to mention the memory model. Sorry, but it was a bit late. I am using the large memory model, the code is about 95K, the data is probably about 20K, and the heap is about 30K at peak. I am linking with the LLIBCE.LIB, and my pointers when listed out in the debugger are far pointers. Also, ds = ss. Can you help me now? If not, then I am going to have to trace the stack out by hand, and I do not look forward to this at all. Thanks again, Troy - \/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////\/ \ Undergraduate Student in \ Troy Holly / \ Mathematics / 445 Leslie Ave; SLC UT 84115 / \ && \ (801)486-0370 / \ Computer Science / Arpanet: u-tholly@ug.utah.edu / \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////
hollen@zeta.megatek.uucp (Dion Hollenbeck) (07/12/89)
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
hollen@zeta.megatek.uucp (Dion Hollenbeck) (07/12/89)
From article <3943@s.cc.purdue.edu>, by aic@s.cc.purdue.edu (George A. Basar): > In article <2163@wasatch.utah.edu>, u-tholly@wasatch.utah.edu (Troy Holly) writes: >> 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 > > > Have you checked your memory model and the lib you are linking > with to be sure they match? Could be that you are mixing models and the > lib routine expects both selector:offset and you are only pushing offset > or selector(incorrect one):offset (in the case where ds != ss) As I replied to the original posting, I, too, started to suggest this, but after re-reading the original and noting that "after executing several times with no problems" the function call would fail, I removed the comment about linking to the wrong libraries. If it exhibited the failure behaviour on EVERY iteration, I would be inclined to agree with George that improper linking was the culprit, but upon re-reading the original posting, I don't think so. It is, however, remotely possible that the function could be grabbing garbage data from the wrong place time after time and just by chance it conforms to some valid floating point number and therefore only fails some of the time, but this is highly unlikely. The other question to pose is: "Are your floating point results REASONABLE when the function does not fail?" Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 uunet!megatek!hollen or hollen@megatek.uucp
t-stephp@microsoft.UUCP (Stephen Poole) (07/13/89)
In article <2169@wasatch.utah.edu> u-tholly@wasatch.utah.edu (Troy Holly) writes: >If not, then I am going to have to trace the stack out by hand, and >I do not look forward to this at all. Thanks again, > >Troy - [Having floating point invalid problems] Before you do a stack trace by hand you might just want to check the possibility that between the point where your last call to the math function worked and THIS call you had a stray pointer blast the floating point emulator code. Not knowing anything about your code it's hard to say if examining this is a monumental task or not, but if it's towards the trivial side then I'd definitely look there first. -- -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- -- -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- -- soft. Believe me, nobody here pays attention to my opinions! --
shiao@cunixf.cc.columbia.edu (Dennis Shiao) (04/11/90)
Does anyone have any information(general->specific) on Object Oriented Programming ? A final project in one of my classes entails writing a processor to take C-- code (C, minus some functionality -- a pseudo language) and produce from it valid C code. Topics of Interest: Symbol Tables Parse Trees Object Oriented Programming Lex Yacc Thanks a lot.... Dennis internet --> shiao@cunixf.cc.columbia.edu bitnet ----> shiao@cunixf.BITNET