Path: utzoo!utgpu!watmath!clyde!att!ucbvax!RICHTER.MIT.EDU!krowitz From: krowitz@RICHTER.MIT.EDU (David Krowitz) Newsgroups: comp.sys.apollo Subject: Re: Problems with invalid stack frame Message-ID: <8812092341.AA05158@richter.mit.edu> Date: 9 Dec 88 23:41:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 49 That particular error message means that your program has managed to trash its stack (the memory area where temporary variables and subroutine return addresses are kept). Normally, when a program dies, you will get a traceback of where the program was executing when it trapped the error. This is done by the OS taking hold of the stack of the process that got the error and then looking at the entries in the stack to find the route which the program took to get to the point where the error occurred. A sample traceback (for a program which I control-Q'd out of) looks like this: $ dspst -a ?(sh) "/com/dspst" - process quit (OS/fault handler) In routine "GDM_$$DN3000_VALIDATE". $ tb process quit (OS/fault handler) In routine "GDM_$$DN3000_VALIDATE" Called from "SHOW_VALUE" line 569 Called from "SHOW_LINE" line 645 Called from "BAR_CHART_$DISPLAY" line 1740 Called from "DSPST" line 816 Called from "PM_$CALL" It is possible for a program to overwrite its own stack area, thereby destroying the list of subroutine return addresses and making it impossible to trace where the error occurred. Common methods of trashing your stack are: 1) calling a subroutine which allocates a very large array or arrays [the stack contains 256KB of space], 2) overflowing the bounds of an existing array, 3) calling a subroutine with 16-bit integer arguments when the subroutine actually takes (and modifies) 32-bit arguments [in some rare instances]. #1 and #2 are the most common causes, and they will only show up when your input data just happens (by chance) to cause the program to use those memory locations which overflow into one of the subroutine return address on the stack. If they overflow into other variables on the stack, then you may never see the error. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)