'Stack Underflow Causes Purple Plague'
So, what happens in a real part if there is a stack underflow???
It's not too hard to write a dud piece of code that calls a
subroutine but for some reason never comes back. One method of
writing such evil and dastardly code is to put a GOTO inside a
subroutine that points outside the subroutine. The code never
executes the RETURN or RETLW statement. (Don't ever try this at
In a simulator, this will eventually give you an error message.
such a subroutine 8 times and you've exceeded the eight level stack
in a PIC. What happens in the real part? Does it reboot? Does
go off into LaLa land and begin executing uninitialized code? Does
it chug merrily along? Does it ignite a global epedemic of Purple
Sorry for sending duplicate messages to the list.
> So, what happens in a real part if there is a stack underflow???
I found another possible way stack underflows can occur.
I have some lookup tables, with 16 values in them
What happens if I enter such a table with a number greater than 15?
This is unlikely. I was worried this could happen, so I put
GOTO ERRORHANDLER after the 16th value in the table. At least we'd
goto someplace under control.
Mistake! This causes a stack underflow. I've placed a GOTO $ at the
end of the subroutine now. It keeps branching back to itself (GOTO
$ is like SELF GOTO SELF) until it generates a watchdog timeout.
Then we are back to a controlled state. Presumably a watchdog
timeout clears the stack, No?
Otherwise, we're back to Purple Plague........
|On Thu, 9 Apr 1998 13:51:49 +0000 Lawrence Lile <toastmaster.com> lilel
>I have some lookup tables, with 16 values in them
> ADDWF PCL,F
> RETLW 0
> RETLW 1
> RETLW 2
>What happens if I enter such a table with a number greater than 15?
>This is unlikely. I was worried this could happen, so I put
>GOTO ERRORHANDLER after the 16th value in the table. At least we'd
>goto someplace under control.
The goto will only execute if you enter with W=17. If W is greater than
17, the program will go to whatever code is after the table. Even worse,
think of what happens if W=0xFF! The ADDWF PCL,F instruction will
execute indefinitely. If you're uncertain that W will be in range,
perhaps the best fix is to check the value of W before exectuing the
computed goto. For tables with a length of a power of 2, it is real
simple to just ANDLW the potentially troublesome high bits of W to zero.
Good bombproof coding should also set up PCLATH (if applicable) before
every table access as well. Checking the value before launching into the
table will fix anything but a hardware malfunction that alters W. In
that case, all bets ar off what the PIC will do. Hopefully your
strategically-placed clrwdt won't execute.
>Then we are back to a controlled state. Presumably a watchdog
>timeout clears the stack, No?
The stack is never cleared by any sort of reset. It doesn't have to be
cleared. The pointer can just roll over and over, making the stack more
like a circle than a line. A CALL or interrupt will store data and move
the pointer forward one. The next RETURN will move the pointer back one
and recall the address that was last pushed. Wherever it starts, after 8
pushes the pointer is back where it started.
Going back to the top of your program and restarting it, whether by WDT
or a direct GOTO will make any data in the stack irrelevant. The entire
tree of calls will be done over again, storing the proper return
addresses wherever the pointer starts from. So if you want to crash and
restart everything after an unrecoverable error, just disable interrupts
and goto 0. This simulates a hardware reset fairly well.
There shouldn't be any need to do this though, the program needs to be
bug-free to have much chance of working.
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...