Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!apollo!r_miller
From: r_miller@apollo.COM (Roger Miller)
Newsgroups: comp.sys.apollo
Subject: Re: Mystery Error (unable to unwind stack)
Message-ID: <42de930d.8b6c@apollo.COM>
Date: 26 Apr 89 21:02:00 GMT
Organization: Apollo Computer, Chelmsford, MA
Lines: 42
Expires:
References:
Sender:
Reply-To:
Followup-To:
Keywords:

In reply to Dave Hayes (and of interest to other SR9.7 users):

>   > Now you're well on your way to debugging the problem.
>   Am I? What is DDE? What does all that garbage mean?

Sorry, I should have pointed out that this was all based on SR10.  DDE
(Distributed Debugging Environment) is the SR10 debugger; it replaces
debug.  The "-full" option to tb is also new at SR10.

Under SR9.7 the tools aren't as sharp.  You can run the program under
debug to catch the original fault before the stack unwinder is invoked.
But if the stack has been corrupted the debugger won't be able to figure
out where it is either.  It will probably say something like

    (process_5) access violation (OS/fault handler)
    *** Error: Stack pointers invalid; cannot establish valid environment.

Your best bet is probably to use db to find the address where the fault
occurs:

    $ db -g test.bin
    ... startup stuff deleted ...
    access violation (OS/fault handler)
    F     120011
    8076: 4E75                              <----

This tells you that the access violation occurred at address 8076. (The
contents of this address, 4E75, is an RTS instruction.  A routine probably
overwrote its return address on the stack, then faulted trying to return.)
To locate address 8076 go back to debug.  With the VA command and some trial
and error you should be able to find the routine containing it.  Then
"BREAK -VA 16#8076" and look in the source display for the line marked with
a breakpoint symbol.

>   But how does this explain that I've gotten this error from shell commands
>   like ARGS and WHILE?

This is just a guess, but since programs run in the same process as the
shell at SR9.7 it is possible for a stray write to clobber some of the
shell's part of the stack.  The offending program may be long gone by the
time the problem shows up.  (SR10 adopts the Unix model of invoking each
program in a separate process, so this is no longer a problem.)