shf@well.UUCP (Stuart H. Ferguson) (02/10/88)
I'm experiencing a rather nasty and majorly head-scratching problem with a program I'm writing. It GURU's on the call to exit(0). It gives GURU meditaion number usually 3 or 4 at address 0020D018. It's quite consistent and repeatable, but I am totally at a loss to understand the cause. The program opens a window with REPORTMOUSE set in the IDCMPFlags. On receiving a MOUSEMOVE message it tests a flag. If the flag is true, it calls a function to display the coordinates of the pointer; if it's false, it does nothing. The flag can be toggled on and off with a gadget. As long as I don't turn the flag on by hitting the gadget, everything works fine. But if I hit the toggle, drag the mouse around a bit, hit the toggle again and exit, the program crashes as described above. I traced the problem as far as I could and found that the coordinate display function appeared to be the key. If the function didn't get called, no crash. If the function is allowed to execute even the first two lines of its code, the crash occurs. The weird thing is this: I wrote in some test code so that when I pressed a key, the RAWKEY+code value would call the function in question. So in this case, the exact same function will be called from within the same subroutine (the HandleMessage routine). I start the program and press this key all over the place. No crash. I can only conclude that it's not the function *per sae*, but some more complex interaction between things. It doesn't appear to be a stack problem. I increased the stack by a factor of 4 and it still crashed. Here's the last peculiar piece to this puzzle. The coordinate display function has several auto variables, to wit: float v[3]; BOOL flag[3]; UBYTE s[8]; When I made these GLOBAL variables instead of auto variables, the crashes stopped. Why this should happen I have no clue (unless it was a stack problem, which it shouldn't be since these declarations should take only about 26 bytes of stack space). I'm using Manx Aztec C v3.4a. Consider also that this is only a small part of a very large and complex program, so there could be other sorts of interactions going on that I haven't described. Help! My brain hurts! Even stories of similar crashes and their causes could get me looking in the right places. Thanx in advance for any help! -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) (02/11/88)
In article <5209@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: > float v[3]; > BOOL flag[3]; > UBYTE s[8]; > >When I made these GLOBAL variables instead of auto variables, the >crashes stopped. This would make tend to think that the function is indexing out-of-bounds. When it's auto, it trashes important stuff. When it's global, by chance it trashes unimportant stuff. Another possibility is different data alignment.
msl5864@ritcv.UUCP (Michael S. Leibow) (02/13/88)
In article <5209@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: > >I'm experiencing a rather nasty and majorly head-scratching problem with >a program I'm writing. ...... ...... > float v[3]; > BOOL flag[3]; > UBYTE s[8]; The problem is with the BOOL. The BOOL is defined as a "short" when it should be an "unsigned long". If you edit your header file that has the "BOOL" typedef in it and make a BOOL, a ULONG, you won't have any more problems. I did not like the idea of editing my header files so I just make a new type called BOOLEAN. typedef BOOLEAN ULONG; Hope this helps... -- Michael S. Leibow UUCP: {allegra,seismo}!rochester!ritcv!msl5864 CSNET: msl5864%rit@csnet-relay.ARPA