auto generated invalid variable names

As stated here:

https://de.mathworks.com/matlabcentral/answers/348701-reguarding-assignin-acceptable-name-for-variable#comment_701596

I get an error

Error using opt705 (line 86)

Invalid variable name "_symans_[[32, 0, 7034898]]" in ASSIGNIN.

Error in run (line 91)

evalin('caller', strcat(script, ';'));

During a script run.

The according main script opt705.m and related functions are attached.

I assume, the error has a random nature, so I don't know how to reproduce it directly. However, I have saved data files until the crash, so it would be helpful, I could post the matfiles generated by the script so far (until it crashed).

[Walter Roberson]

It has been running 80 minutes so far on my system without difficulty.

[Alexander]

yeah... I started the script at Thursday and it failed during the last night... so the runtime was about 1.5 days or so... with generating about 1 optimization result per 4 hours.

[Walter Roberson]

It would have been nice ahead of time to know it would run 1.5+ days...

[Adam Danz]

Alexander, my approach when running potentially long analyses is to always use dbstop if error, even when I don't expect an error. That way if there is an error, the local variables are still accessible in the workspace and I can troubleshoot. I suggest you take this approach and carefully look at your code in debug mode after an error is detected.

[Walter Roberson]

How long is this supposed to go on? It has finished 24 for me so far and shows no sign of stopping. Close to 2 1/2 days so far. No hint of a problem.

[John D'Errico]

I don't use dbstop. For example, I have a code that has now run for something like 700 hours of run time. I'll set it running whenever my computer will be idle. But I have it set to record any progress made as it goes. It just saves a record of progress at each point where that makes sense (roughly every 10-30 minutes of run time.) In this application, I just use setpref, to store the information as a preference. This lets me check for progress using getpref. And it remembers everything it needs between sessions.

[Adam Danz]

I'm going to try that some time. Thanks, John.

[Alexander]

Walter, the script is supposed to produce 60 outputs (i.e. 5 days or so).

I have a machine where the script is running without a problem and one where it crashes every 4-10 runs in the parfor loop. So, my current opinion is, that I have some ulimits to reset and then to retry...

[Jan]

dbstop if error has the disadvantage, that the active debugging disables the JIT acceleration - perhaps partially. Reoredering the lines is a powerful method of the JIT, but then the debugger is confused. In consequence some loops took 10 times longer on my computer. I've tested this when I used R2009a, and assume, that the effect did not change.

[Walter Roberson]

If it crashes every 4 to 10 runs in the parfor loop and I have 29 results so far, then can I assume that it is not going to crash, and abort it instead of leaving it running another 4-ish days?

[Alexander]

Hmm... yeah, I think so.

[Jan]

@Alexander: Running a script inside the workspace of the caller is ugly. I do not know, if this must necessarily cause the observed problem, but especially if running in parallel, the computing is more fragile.

The error message is strange:

Error using opt705 (line 86)

Invalid variable name "_symans_[[32, 0, 7034898]]" in ASSIGNIN.

Line 86 in opt705 is:

parfor i = 1:length(x)

I do not see, how this line can cause this error.

[Alexander]

yeah... I don't see any reason too, why the line should cause any problems. This is why I posted the problem here :)

Another problem occures, which states

*** Error in `/opt/R2018b/toolbox/symbolic/mupad/../../../bin/glnxa64/mupkern': malloc(): smallbin double linked list corrupted: 0x000000000b731180 ***

This is why my current assumption is, that I have to tweak my ulimits. However, the script is running since two days now (even after the message about malloc), and I need my results more, that a stable script. So, if it crushes again, my next try will be to experiment with ulimits, if not, the problem will become minor in my eyes anyway.

Anyway, thanks @all for have a look into the problem...