#5617 closed defect (fixed)
This model crashes omedit
Reported by: | massimo ceraolo | Owned by: | Adrian Pop |
---|---|---|---|
Priority: | blocker | Milestone: | 1.14.0 |
Component: | New Instantiation | Version: | v1.14.0-dev-nightly |
Keywords: | Cc: | Per Östlund |
Description
Steps to reproduce::
1) load open source library "Photovoltaics"
2) load the attached package "TestPkg"
3) open model "SimpleModule"
4) run model -> CRASH
Note that this model has an issue, but should not cause a crash.
In Dymola, this model produces the following message:
Translation of TestPkg.SimpleModule: Missing support for the zero-sized record variable module.diode. The conditions of the following assert statements are always false: assert(mod(module.moduleData.ns, module.moduleData.nb) == 0, "Simple: number of bypassed cells cannot be determined unambiguously"); Translation aborted. ERRORS have been issued.
Attachments (2)
Change History (9)
by , 5 years ago
Attachment: | TestPkg.mo added |
---|
comment:1 by , 5 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Priority: | critical → blocker |
Status: | new → assigned |
by , 5 years ago
Attachment: | script.mos added |
---|
comment:2 by , 5 years ago
Component: | OMEdit → New Instantiation |
---|
comment:3 by , 5 years ago
In Linux I got a floating point exception in ExpressionSimplify. So I am guessing somewhere there is an undefined value returned. (Note that I pass the entire frontend)
==13528== Process terminating with default action of signal 8 (SIGFPE) ==13528== Integer divide by zero at address 0x1009C53D8E ==13528== at 0x5FEEA03: omc_ExpressionSimplify_simplifyCall (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FEF8E5: omc_ExpressionSimplify_simplifyWork (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FF7A05: omc_Expression_traverseExpBottomUp (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FF7250: omc_Expression_traverseExpBottomUp (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FEC064: omc_ExpressionSimplify_simplify1FixP (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FEC4E8: omc_ExpressionSimplify_simplify1WithOptions (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FEFC75: omc_ExpressionSimplify_simplifyWithOptions (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5FCF748: omc_ExpressionSimplify_condsimplify (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5BCC70E: omc_BackendVarTransform_replaceStatementLst (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5BD0222: omc_BackendVarTransform_replaceEquation (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5BD0989: omc_BackendVarTransform_replaceEquations2 (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so) ==13528== by 0x5BD0AB8: omc_BackendVarTransform_replaceEquations (in /home/marsj/OpenModelica/build/lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so)
comment:4 by , 5 years ago
There seems to be a couple of different issues here. With the old frontend it fails in the backend, because it uses the ExpressionSimplify module from the frontend to simplify some expressions including mod(3, 0)
from the assert in the description. I've changed this so that ExpressionSimplify ignores mod(x, 0)
expressions, which instead causes an error during runtime. Perhaps it would be better to give an error earlier, but an error is at least better than crashing.
The new frontend fails earlier since it tries to do a similar simplification during the frontend phase, and for some reason only div
and rem
checked for 0 but not mod
. I fixed that too so that an error is printed when trying to constant evaluate mod(x, 0)
in certain situations. However, the error is ignored during expression simplification (we also don't have the source information available there), since it's not really an error to fail to simplify an expression, so it's just ignored like in the old frontend and left to the backend to handle. We could perhaps add a check in the VerifyModel module to catch the issue earlier.
The new frontend has some other issues with the model though, which causes the model to be unbalanced. This is one of the array modifier issues that I've been trying to fix for some time, so no need to open another ticket for that.
comment:5 by , 5 years ago
Milestone: | 1.14.0 → 1.15.0 |
---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.
This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0
comment:6 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
The model crashes when
translateModel
is called. The only useful info I found in the stack trace is,