ExecuteProcess() aborted, recursion level too deep

[Steve Rowe]

Hi,

I am converting a system from single threaded to fully utilise PI.

I am getting erratic errors giving both the following errors (ie it doesn't always happen)

ExecuteProcess() aborted, recursion level too deep

and

Process "Name" :: System stack overflow, process terminated

The instance is pretty rule light and basically a processing instance, taking in a file doing a bunch of work and then spitting it out again.

The available information on the system stack overflow error seems to say this a rule / feeder problem, can anyone confirm with accuracy that this is the only circumstance in which this error occurs? Or are rule / feeder issues just one of the reasons it can occur?

None of the TIs call themselves so I am also confused about the recursion message, I know you can get this if you set a TI up to call itself in an infinite (or long) loop but does any know any other reasons that this message can be triggered?

Can anyone confirm that if you get a recursion error you will get a stack overflow error too for any jobs that were in flight when the error occurred? I'd like to establish if I have two independent errors or if one problem is triggering both messages, which would seem to be a reasonable assumption.

My gut feel is that I have an infinite / long loop buried somewhere that bridges many TIs and that this route through the TIs only occurs in a specific set of circumstances. I've yet to do the in depth analysis required to establish this yet.

Cheers and TIA for any pointers.

[Steve Rowe]

One other thing that I am doing that I don't normally do is having around 30 global variables declared. With the way my jobs are set up it is possible that they are set-up say 15 times at the same time (basically 3 independent jobs each running on 5 threads, using the same set of global vars).

So at given point in time I could have the same global var (with the same value) declared 15 times, giving 450 in total. This seems quite small for stack of memory for holding variables.

Any views?

Meant to say we are running 10.1.1, can't tell you the exact release I'm afraid....

Cheers,

[BrianL]

You will get the "recursion level too deep" if you get down 100 levels of nested ExecuteProcess calls.

Stack overflow is much more difficult to determine, but could very easily be related to very large counts of nested ExecuteProcess calls. Does each process declare all those global variables. The more variables you declare the more stack space will be consumed. I would expect stack space to be specific to a single TI, however I would also expect each nested ExecuteProcess call to grow the stack. The two usual approaches to avoiding this is to limit the number (depth) of nested ExecuteProcess calls and to reduce the number of global variables and/or parameters variables.

[BrianL]

Oh, and I would expect the recursion level too deep error message to also spit out the system stack overflow message as well.

[Steve Rowe]

Hi Brian, Thanks for the information sounds like I only have a recursion problem.

The sequence that is failing doesn't have global vars (but others running at the same time do). My approach with the globals has been to declare and define them for all jobs in a single TI and then call this TI from the initial job of the various chores. This works well for me as I can declare the value of all my unchanging vars and do my error checking in single place. Only a subset of the global vars are valid for each job though so it sounds like this approach may be flawed from a stack perspective.

Although it sounds like it is not directly related to my problem, it would be very useful to have some detail on the size of the stack, how it is consumed and what objects share a stack and which have their own. I suspect it is pretty hard to break these days, the only time I really encounter it is the classic example of rolling a feeder forwards over a long time dimension for opening balance calcs.

Thanks again for the pointers, much appreciated.

Cheers,