🚀 go-pugleaf

**** CROSSPOST: Followup -> gnu.gcc.help

In article <1992May21.105156@gothamcity.jsc.nasa.gov>, shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC]) writes:
|> The following is a stack trace of my program execution:
|> 
|> (gdb) step
|> 304         guiDoEvent();               /* handle one interface event */
|> (gdb)
|> guiDoEvent () at ./sys/gui.c:120
|> 120       XtNextEvent(&event);
|> (gdb) where
|> #0  guiDoEvent () at ./sys/gui.c:120
|> #1  0x1b56c in supEventLoop () at ./sys/supervisor.c:304
|> #2  0x1b3e0 in supWorkExercises () at ./sys/supervisor.c:255
|> #3  0x1b20c in supHandleStudents () at ./sys/supervisor.c:188
|> #4  0x1b088 in main (argc=1, argv=0xf7fffb44) at ./sys/supervisor.c:134
|> (gdb) next
|> 121       XtDispatchEvent(&event);
|> (gdb) where
|> #0  guiDoEvent () at ./sys/gui.c:121
|> #1  0x1b56c in supEventLoop () at ./sys/supervisor.c:304
|> 
|> 
|> It seems that XtNextEvent is destroying my stack.
|> Is this caused by X?
|> I've never waited until 5 function calls deep to use  XtNextEvent.
|> This  shouldn't be a problem, but my eyes tell differently.
|> Is this actually a compiler (gcc) or a machine (SPARCstation 2) problem?
|> Could something else be corrupting my stack, but no show immediately in gdb?
|> How does the bottom of the stack get corrupted?
|> 
|> Obviously this causes a bit of pain when supEventLoop tries to return
|> execution to its caller. (i.e. Segmentation fault)
|> 
|> Help me, I'm melting...
|> 

Ouch!

I found the problem.  The following code is evil:

XEvent          *event;

  XtNextEvent(&event);
  XtDispatchEvent(&event);


It destroyed the bottom of my stack, bad code, bad code!
(The XEvent structure being ~24 bytes and a pointer being ~4 bytes, this
 can tend to write all over your execution stack. In my case obliterating
 the return address)

Which got me to thinking...

 ``Why didn't -DNeedFunctionPrototypes=1 make the compiler scream at me?''

I recompiled it, with the erroneous code, to see if I had ignored my
omniscient compilers warning.  But, low and behold, it had no complaint.

gcc -g -DDEBUG -DNeedFunctionPrototypes=1 -Wall -c file.c

Did not elicit even a warning when I compiled the code that sent an incorrect
parameter.  Why, oh, why did it not warn me?
-- 
Bill Shirley
shirley@krakatoa.jsc.nasa.gov
(PS. I didn't write this code, it must of been my evil twin ;-)