fdfishman@watcgl.waterloo.edu (Flynn D. Fishman) (09/14/88)
Hi, I have a problem that has been bugging me lately I am working on a rather large database application on the Amiga in Manx C. It has lots of variables and lots of routines, etc. etc. I find that some of my variables get changed arbitrarily for example I have a loop that counts from 0 to fieldlength, where fieldlength is a global generally 12. What happens is it counts from 0 to 10 and then from 1 to 10 over and over again for ever. This problem crops up in different places at different times, and can be removed by adding or removing a line of code, (but then it sometimes goes else where). The problem is not limited to variables either, sometimes it forgets where a routine is and jumps to the wrong location. I have noticed this problem on several programs, including a couple at work. I have also noticed that SDB has troubles with large programs and sometimes gurus on random routine calls. I have also tried the +c and +d compile options to no avail So what am I doing wrong? Does anybody know what is going on? How do I fix it? I am using Manx 3.60a Amiga 2000, with 5 meg, a2090 card and 20 meg generic drive I also work in interlace mode. Thanks Very Much -- FDFISHMAN (Flynn D. Fishman) @ WATCGL (but you can call me Flynn) UUCP : ...!{decvax|ihnp4|clyde|allegra|utzoo}!watmath!watcgl!fdfishman ARPA : fdfishman%watcgl%waterloo.csnet@csnet-relay.arpa2 CSNET : fdfishman%watcgl@waterloo.csnet
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/15/88)
In article <5816@watcgl.waterloo.edu> (Flynn D. Fishman) writes: >The problem is not limited to variables either, sometimes it forgets where a >routine is and jumps to the wrong location. I have noticed this problem on >several programs, including a couple at work. >So what am I doing wrong? >FDFISHMAN (Flynn D. Fishman) @ WATCGL (but you can call me Flynn) This is sounds very suspiciously like a stack problem. Before running your program type "Stack" to figure out the stack size, then make a rough approximation of how much stack is being used in the routine in question. Do this by adding up the sizes of all local variables in every routine "above" and including the routine in question. Then add another 1K for DOS kinds things. If that number is bigger than or even close to the Stack number you got above then try doubling the stack size. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/15/88)
In article <68270@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <5816@watcgl.waterloo.edu> (Flynn D. Fishman) writes: >>The problem is not limited to variables either, sometimes it forgets where a >>routine is and jumps to the wrong location. I have noticed this problem on >>several programs, including a couple at work. >>So what am I doing wrong? >>FDFISHMAN (Flynn D. Fishman) @ WATCGL (but you can call me Flynn) > >This is sounds very suspiciously like a stack problem. Before running >your program type "Stack" to figure out the stack size, then make a rough >approximation of how much stack is being used in the routine in question. >Do this by adding up the sizes of all local variables in every routine >"above" and including the routine in question. Then add another 1K for >DOS kinds things. If that number is bigger than or even close to the >Stack number you got above then try doubling the stack size. > >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. Since Flynn uses Manx he can turn on automatic stack checking. It can be done with a compiler option, although I don't know which one offhand. -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]