nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Script runs through but terminates with error

medini_1035403171

Hi Jan,

We are finally almost done with the import script we developed to import a quite large analysis. The overall script has become quite large as well and takes a few minutes to execute. It executes every command without any errors until the end (checked with pop up as last command) but does not finish and close the progress information window.

We tried it on two computers: The one shows the error "Failed to execute Java Script: feature 'FailureMode' not found" which I do not understand.

The other computer run for like half an hour after the actual commands are executed and terminates with the error message "GC overhead limit exceeded". I guess this a memory issue. However, using -Xmx4G in the ini file resolved it and now this leads to the same error like on computer 1.

So any idea about this? Honestly, it's kind of a silly situation that the script is done but cannot be executed because of some other topics :-)

Cheers,

Johannes

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1024169437

Thanks Johannes, I understand. So the problem is the traceability from the error message to the script file.

I played a bit with a simple example:

finder.findByType(Metamodel.safetyModel.Measure).size();

finder.findByType(Metamodel.safetyModel.Failure).size();

finder.findByType(Metamodel.ssysml.Malfunction).size();

"Finished"

and indeed the error message is weak. Fortunately the error log is a bit more descriptive.

The log says:

so at least for the worst case you can find some hint.

Happy Scripting

Jan

All comments

medini_1024169437

Hi Johannes,

that's indeed a unfortunate situation. I could think of a few reasons, but I am just speculating. The script is executed inside a transaction, if it really runs several minutes, all changes are finally applied at the end of the transaction, so if you created tons of objects, there might be a huge change set in the end resulting in a memory jump. However, the mentioned error is strange and sounds more like a scripting error.

Any chance to get hands on script and sample data? Its difficult to judge otherwise.

Jan

medini_1035403171

Hi Jan,

Sorry for the confusion: You were right. Actually, it was a scripting error. I found it. I just wonder why the error does not pop up at the moment when the script runs through the erroneous line.

I observed a similar behaviour when I use the debugger, pause the execution and push the cancel button of the progress monitor: the script still executes a few more lines before it terminates. In our case, the erroneous line was not that far from the end. Is this a scheduling topic and the same cause?

Thanks,

Johannes

medini_1024169437

Ah, now I see clearer. Well, canceling the java script interpreter is a topic of its own. Pressing the Cancel button internally just sets a flag. The engine is checking the flag periodically to bail out in case the user requested to cancel. If you are stuck in the debugger that check is most likely not done. Note that the "periodic check" is done at byte code level, not JS script level. I think every 100 byte code instructions.

Anyway, so the issue is solved now?

Jan

medini_1035403171

That makes sense. And the error which occurred in our script is not displayed during the execution of the erroneous command because of the same reason?

The issue is solved, yes. Thanks!

medini_1024169437

Hm, no, that should not be related. If you give me a hint, I may try to reproduce it.

Jan

medini_1035403171

I can try to reproduce the error and provide the script to you if that helps you with your work. Just let me know.

Johannes

medini_1024169437

Hi Johannes,

if it does not eat up too much time, yes, that would be appreciated.

Jan

medini_1035403171

Okay, I could simplify the erroneous script dramatically. Simply execute the following:

Metamodel.sysml.Malfunction;

It will terminate with an error but not display the line. This is obviously no problem in this case but can become silly if you work on larger scripts with numerous files and don't know about the error behaviour.

medini_1024169437

Thanks Johannes, I understand. So the problem is the traceability from the error message to the script file.

I played a bit with a simple example:

finder.findByType(Metamodel.safetyModel.Measure).size();

finder.findByType(Metamodel.safetyModel.Failure).size();

finder.findByType(Metamodel.ssysml.Malfunction).size();

"Finished"

and indeed the error message is weak. Fortunately the error log is a bit more descriptive.

The log says:

so at least for the worst case you can find some hint.

Happy Scripting

Jan