LOG_NLS_V fails due to memory overrun

[Francesco Casella]

Please consider the attached test case. The log output comes to this point:

LOG_NLS_V         | info    | SOLVING NON-LINEAR SYSTEM USING HOMOTOPY SOLVER
LOG_NLS_V         | info    | EQUATION NUMBER: 1201
LOG_NLS_V         | info    | TIME:  0.0000000000e+000
LOG_NLS_V         | info    | number of function calls (so far!):  0
LOG_NLS_V         | info    | System values [295-dim]

and then the simulation process doesn't proceed anymore.

If you reduce N to 300 or less, everything goes as expected. I guess there are some strings which become too long when there are more than about 300 unknowns in the initial system, which is pretty normal for steady-state initialization of energy systems.

Unfortunately, this completely prevents any debugging.

[Francesco Casella]

Test case

[crupp@…]

+1

I've been intending to report this for a while, but haven't had a chance. The problem is caused by a buffer overflow in nonlinearSolverHomotopy.c in the debugMatrixXXX functions (multiple locations). It happens for large models with large matrices to report because a whole row is put into a single 4096 char buffer.

There are also places in the other nonlinearSolverXXX.c files where the same procedure is used for LOG_NLS_JAC. These should probably be fixed as well.

[Francesco Casella]

As a general rule, we should not have code in OMC which crashes or is unsafe if

• the number of unknowns in a strong component
• the number of states in a model
• the number of variables in a model
• the number of equations or the number of initial equations
• etc.

goes above a certain, otherwise unspecified threshold. Never assume anything is "small enough". Things like limited filename length, or limited variable name length, or limited number of file icons, are still plaguing modern OSs and software. Let's try to avoid this in OMC and build the code to stand for the next 20 years (Dymola is already 20 years old).

In this case, I suggest we always use dynamic memory allocation for string buffers. In particular if it is used for debugging, where a bit of slowdown is perfectly acceptable. Or maybe introduce some macro so that a fixed size buffer is used if the size is less than a certain threshold, otherwise dynamic memory is used.

[Lennart Ochel]

I fixed memory overrun inside nonlinearSolverHomotopy.c with ecd1bc6.

[Lennart Ochel]

Replying to crupp@…:

There are also places in the other nonlinearSolverXXX.c files where the same procedure is used for LOG_NLS_JAC. These should probably be fixed as well.

I'm going to fix that as well.

[Lennart Ochel]

This should be fixed with 1abd255.
Please reopen this ticket if there is any issue with my changes.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed