What causes an "All call stacks are in use" error?
As a Dexterity developer you might have come across the following error:
All call stacks are in use. Cannot start script.
This post will describe what call stacks are (from a Dexterity perspective), how they are used and what causes this error to be generated.
Note: I will start by saying that this topic is covered very well in the Dexterity Programmer's Guide (Volume 2, Part 5, Chapter 24) and also in the Dexterity Help file (search for "Call Stacks", then click on "described"). Thanks to Steve Kubis and the Dexterity documentation team.
A call stack is a mechanism for managing the processing of scripts. In programming terms, a call stack is a Last In First Out (LIFO) data structure that stores the state of a script (variables, next command to execute, etc.). When Script A calls a child Script B, the state of Script A is placed (or pushed) onto the call stack while Script B runs. When Script B is completed, the state is restored (or popped) back from the call stack and Script A continues running from just after the call to Script B.
When Dexterity calls global and form level functions and procedures, all the processing is handled on the single call stack. This can be visualised as a pile of paper sheets and as each new script runs a new sheet is placed onto the pile and then removed when that script is completed.
However, under certain circumstance Dexterity can execute code which requires its own call stack. To support this, the Dexterity system has eight (8) call stacks. One call stack is dedicated to background processing which leaves seven (7) call stacks for foreground use.
There are three types of processes which can start a new call stack being used:
- Procedures that are called automatically by Dexterity, such as the global procedures Security and Pathname.
- RW Functions called by Report Writer calculated fields as User Defined Functions.
- run script commands which executes the script attached to the change event of the window field specified.
The problem with running out of call stacks and generating a call stack error is usually caused when developers over use the run script command. The two examples below will explain how the call stacks are used with the run script command:
Example 1: Script A
run script 'B';
run script 'C';
In example 1: when Script B is executed a second call stack is used. But once Script B is completed the call stack is no longer needed and the execution returns to the original call stack. Then Script C is executed in the second call stack. This sequential calling using the run script command only uses one additional call stack and so does not cause the error condition.
Example 2: Script A
run script 'B';
Example 2: Script B
run script 'C';
In example 2: when Script B is executed a second call stack is used. Script B in turn executes Script C and so uses a third call stack. This nested calling using the run script command uses an additional call stack for each nested call. As there are only seven call stacks available for foreground processing, you can only have six levels of nested run script commands.
The following diagram from the Dexterity manuals shows the Background call stack and the seven Foreground stacks. Note how the seven stacks are all used because of six nested run script commands.
If a 7th nested run script command is called, an automatically executed procedure is called (by opening a form or table), or a report is run which calls a RW function; the system will have no call stacks available and so produce the error:
All call stacks are in use. Cannot start script.
One example I have seen of this issue was on a maintenance window which had nested run script commands to update fields on the window depending on other fields on the same window (for example: disabling fields depending on a checkbox). When the window used by itself there were no issues. However, when the window was opened by a drill down, there was at least one more run script command and the error occurred. This shows how using too many nested run script commands might not break the code all the time, but could cause issues when called by different methods.
It is recommended that developers don't nest run script commands more than 3 levels. This is should help avoid the issue from occurring. Other methods of avoiding the error include using functions and procedures rather than run script commands and using the run script delayed command. The run script delayed command starts the specified field change script after all foreground processing is complete and so does not use an additional call stack.
For a related post on this topic where this error is caused by Regional and Language settings see Janakiram's post below. The difference in the control panel settings must be altering the behaviour of the code in such a way to make it attempt to use one more call stack:
Hope this information is useful.
David