Stack Underflow

Hello!

I've written a script that in the future is supposed to be ran from batch/command line. The script works perfectly from the DXL Editor, however when I run it from the command line, I get the following error after a while:

-R-E- DXL: <Line:0> Stack Underflow
-R-I- DXL: <Line:0> DXL maximum instruction count reached (infinite loop?). Extend limit with pragma runLim,<count>.

However I do have pragma runLim, 0 at the very beggining of the script. I even tried adding pragma stack, 20000000 after a few tries, but nothing changed.

I'd be glad for any help!

Thank you very much in advance!

Re: Stack Underflow
Mathias Mamsch - Mon Jun 12 03:37:06 EDT 2017

Hmm ... What exactly is this script doing? There are many possible ways of getting a stack underflow, most of them having to do with incorrect function declarations (e.g. returning something from a void function, trying to return arrays, functions, etc.). 

If you are doing anything "special" beside the normal function declarations inside your script you might need to post some code. 

In the meantime try wrapping the whole main script in curly braces, i.e.: 

{
       /// your code
}

which is known to resolve some (parse time) problems. Regards, Mathias

Re: Stack Underflow
HPM2BP - Mon Jun 12 03:41:33 EDT 2017

Well, my script does a lot of things. The code is about 1000 lines long (about half of it is comment for the future developers).

I have 6 voids, and I think nothing else. Based on a few debugging print commands it seems that I get past easily the voids, however it's possible that the script dies once calling a void. The interesting part is that I already called a few voids in the beginning and it had no problem with them there.

Re: Stack Underflow
HPM2BP - Mon Jun 12 03:56:06 EDT 2017

I did some debugging with prints, and it seems that the script gets stuck without a reason. It loops through objects in a module, does things perfectly, however when it's supposed to open the second module, it crashes.

I tried it again with the DXL editor, but no error, it works there perfectly.

Regards, Peter

Re: Stack Underflow
HPM2BP - Mon Jun 12 04:00:58 EDT 2017

Found the exact error. When it loads the next module, it simply fails to do so.

if ((type(iCurrent) == "Formal") and  ....... ){
        ....
        print "done resetting\n"
        mCurrent = read (fullName(iCurrent), false , false)     //Load the module for reading only, hide it for faster processing
        print "loaded next module\n"
        .....

I get the print from the "done resetting", but not the one from the "loaded next module"

Re: Stack Underflow
Mathias Mamsch - Mon Jun 12 04:42:44 EDT 2017

if ((type(iCurrent) == "Formal") and  ....... ){
        ....
        print "done resetting\n"
        mCurrent = read (fullName(iCurrent), false , false)     //Load the module for reading only, hide it for faster processing
        print "loaded next module\n"
        .....

In this case you need to look at the module. It might contain DXL code that crashes the client in batch mode. Try printing the fullnames, and try skipping over the module

if (name mCurrent == "...") continue

. Also try to load standard view, to avoid executing layout dxl (which makes no sense in batch mode anyway):

mCurrent = read (fullName(iCurrent), false , true /* loadStandardView*/)

Maybe it helps, regards, Mathias

Re: Stack Underflow
HPM2BP - Mon Jun 12 04:45:07 EDT 2017

You are right, tried it just a second ago, the standard view solved everything. Thank you very much!

Regards, Peter

Re: Stack Underflow
HPM2BP - Mon Jun 12 06:49:08 EDT 2017

Sorry about declining the answer after I accepted it, but it seems that I got the same error once again, however now it happened with another module. This time I was using settings for read (name, false, true)

Re: Stack Underflow
HPM2BP - Mon Jun 12 07:35:34 EDT 2017

A little update, when I loaded the module by simply calling it by its name from batch, it worked. However I can't invite every module calling them by their names if a problem like this occours, since we are going to have to have this automatized on a Jenkins server.

Re: Stack Underflow
Mathias Mamsch - Mon Jun 12 08:42:31 EDT 2017

You should think about finding the root cause of the problem by examining the DXL inside the modules. You can minimize the foreign DXL code that will be executed, by parameters like "loadStandardView" and you can also disable triggers, but you will not be able to prevent any execution of foreign DXL. 

Once you found the reason, you can maybe find a simple means to get rid of the problem. Obviously some DXL inside the modules is not designed to be run in batch mode. 

Regards, Mathias

Re: Stack Underflow
HPM2BP - Mon Jun 12 08:44:50 EDT 2017

OK, this is the most stupid error I've encountered in Doors so far. It was because of an attribute.

I did the following:

strTempAttr = oCurrent."SW_Status" ""

For some reason I got an error for this command, however when I used

strTempAttr = probeAttr_(oCurrent,"SW_Status" )

Everything went perfectly. I don't even want to know why. I'm so mad at this language right now... The attribute does exist. The object has a value for this attribute. And the object.attribute doesn't work.

Anyways, thank you very much for your help, that forst thing you offered was the root cause of the very first problem.

Have a nice day!

Regards, Peter

Re: Stack Underflow
Mike.Scharnow - Sat Oct 27 06:38:14 EDT 2018

strTempAttr = oCurrent."SW_Status" ""

strTempAttr = probeAttr_(oCurrent,"SW_Status" )

Perhaps you have no read access to the attribut content of this specific object (sorry, I know that this reply is way too late, I just happened to have the same problem and this was my root cause)