alj@bilver.UUCP (arthur johnson) (04/06/89)
Has anyone else experienced the following problems with Lattice 5.02?:
1) You pass a pointer (&variable) to a subroutine, change the variable
within the subroutine (*variable = ???), and then leave. Upon return
from your subroutine, the variable contains crap (variable = 2600000 or
so). Within the subroutine, the value is correct up to actually exiting
the routine.
2) You do a typical scanf (scanf("%d", &feh)). No matter what you type,
feh contains 0.
3) Occasional crashes due to printf (or similarly) trying to write to
location $9 for some reason.
I have a sizeable (600+ lines) image-processing program which evidences
these problems. I will upload it if anyone wants to look at the actual code.
These bugs (?) are causing me much frustration (all my college programs
are written in C). I'd like to hear from anyone else experiencing this
torture.
--
Arthur Johnson Jr. -=> {uiucuxc, hoptoad, petsd}!peora!rtmvax!bilver!alj
-=-=-=-=-=-=-=-=- -=> alj@bilver.UUCP
-=> PLink: DUNG
-=> GEnie: A.JOHNSONJRcmcmanis%pepper@Sun.COM (Chuck McManis) (04/11/89)
In article <493@bilver.UUCP> alj@bilver.UUCP (arthur johnson) writes: > Has anyone else experienced the following problems with Lattice 5.02?: [problems deleted] What is your stack size? This is a classic "our stack is bigger than the memory allocated for it." If you are running from a CLI environment be use the stack command to check it out. If you are running from Workbench you could use your program's icon to set it higher. Look at the local variables in your program, if you are doing image processing have you accidently declared some arrays that end up on the stack? something like : int convolve(img, op) BYTE *img; int op; { BYTE tmpimage[256][256]; /* <-- 64K of stack space right here */ ... } Look through your code and see if you have something like this in it. If so try setting the stack to 100000 bytes or so. --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. "A most excellent barbarian ... Genghis Kahn!"
alj@bilver.UUCP (arthur johnson) (04/13/89)
I set my stack to 150,000. I have a procedure which declares two 128 x 128
integer arrays (i.e., heap o' memory), and the program would exit with a
"Stack OverFlow" recoverable error unless my stack was that high. With a
stack of 150,000, the program would run.
I'm confused - are you saying that my stack size is TOO large for the program
to run properly?
While I'm posting - does anyone know if a public-domain ADA compiler exists
for the Amiga? No? I wouldn't doubt it. 8-)
--
Arthur Johnson Jr. -=> {uiucuxc, hoptoad, petsd}!peora!rtmvax!bilver!alj
-=-=-=-=-=-=-=-=- -=> alj@bilver.UUCP
-=> PLink: DUNG
-=> GEnie: A.JOHNSONJRwicks@umbc3.UMBC.EDU (Mr. Tony Wicks ) (04/17/89)
In article <505@bilver.UUCP> alj@bilver.UUCP (arthur johnson) writes: > > I set my stack to 150,000. I have a procedure which declares two 128 x 128 >integer arrays (i.e., heap o' memory), and the program would exit with a >"Stack OverFlow" recoverable error unless my stack was that high. With a >stack of 150,000, the program would run. > I'm confused - are you saying that my stack size is TOO large for the program >to run properly? Here's the deal. 128*128*4 bytes is 65536 bytes. You have two of these, using exactly 128K of memory. This wouldn't be a problem, except that you have the arrays declared local to a subroutine/procedure. When the procedure is called all of the local variables are placed on the stack (including your arrays). To avoid this you have to declare your arrays globally, and pass pointers to them. If you are using pascal or modula2 this means use a VAR parameter, in C arrays are automatically passed as pointers. Tony Wicks
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/18/89)
In article <505@bilver.UUCP> alj@bilver.UUCP (arthur johnson) writes: > > I set my stack to 150,000. I have a procedure which declares two 128 x 128 >integer arrays (i.e., heap o' memory), and the program would exit with a >"Stack OverFlow" recoverable error unless my stack was that high. With a >stack of 150,000, the program would run. > I'm confused - are you saying that my stack size is TOO large for the program >to run properly? No, your stack may still not be large enough. The Lattice compiler can detect stack overflows when calling Lattice compiled routines but cannot check stack usage when calling DOS or C/A library routines. If you are calling DOS you should have an additional 4K of stack for DOS' usage. (Note DOS uses the stack from the bottom up, rather than the top down so you can often "watermark" it's usage by filling your stack segment with some value like 555555 and then checking to see how many words got obliterated.) > While I'm posting - does anyone know if a public-domain ADA compiler exists >for the Amiga? No? I wouldn't doubt it. 8-) I seriously doubt it. --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. "A most excellent barbarian ... Genghis Kahn!"
dave@dms3b1.UUCP (Dave Hanna) (04/21/89)
In article <493@bilver.UUCP> alj@bilver.UUCP (arthur johnson) writes: > Has anyone else experienced the following problems with Lattice 5.02?: > 1) You pass a pointer (&variable) to a subroutine, change the variable > within the subroutine (*variable = ???), and then leave. Upon return > from your subroutine, the variable contains crap (variable = 2600000 or > so). Within the subroutine, the value is correct up to actually exiting > the routine. > 2) You do a typical scanf (scanf("%d", &feh)). No matter what you type, > feh contains 0. Both these problems can be a result of size mismatch between variables pointed to in the calling routine and what is expected by the called routine. E.g. { long int foo; ... subr(&foo); ... } void subr(bar) short int *bar; { *bar = result; } Since the subroutine is treating the pointer as pointing to a 2-byte value, and has no knowledge of how the calling routine is treating it, it stores the result in the upper two bytes of the long word variable. Also, if you print it out within the subroutine, it will print out to be the expected value. When you get back to the calling routine, foo has had it's top two bytes modified, with the least significant two bytes unmodified, and you try to print it out as a long word quantity. The best thing you could see would be result*65536, which would be puzzling enough. If foo had garbage in the least significant two bytes, it would be even less recognizeable. Same thing with the scanf if feh is a short quantity. Scanf will dump the results into memory as ints (which I think are 32 bits by default in Lattice -- not sure about that) unless the scan format is modified with an 'h' (for half-size). So if feh is a short, you would actually be seeing the upper two bytes of what you scanned, which would most likely be zero. The correct scanf statement in that case would be (I think): scanf("%hd", &feh) All these comments are generic 'C', and do not apply particularly to Lattice. And, of course, this may or may not be the problem. It is a possible source, that's all. Hope it helps. >Arthur Johnson Jr. -=> {uiucuxc, hoptoad, petsd}!peora!rtmvax!bilver!alj -- Dave Hanna, Infotouch Systems, Inc. | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |