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)