Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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)

TestPkg.mo (3.6 KB ) - added by massimo ceraolo 5 years ago.
script.mos (181 bytes ) - added by Adeel Asghar 5 years ago.

Download all attachments as: .zip

Change History (9)

by massimo ceraolo, 5 years ago

Attachment: TestPkg.mo added

comment:1 by Adeel Asghar, 5 years ago

Cc: Per Östlund added
Owner: changed from Adeel Asghar to Adrian Pop
Priority: criticalblocker
Status: newassigned

The model crashes when translateModel is called. The only useful info I found in the stack trace is,

ob = {buf = 0x641132e0 "0x14053f4e : C:\\OpenModelica\\build\\bin\\libOpenModelicaCompiler.dll : boxptr_NFComponent_Component_Attributes_toDAE \n0x1405a0aa : C:\\OpenModelica\\build\\bin\\libOpenModelicaCompiler.dll : boxptr_NFCompon"..., sz = 16384, ptr = 9985}

by Adeel Asghar, 5 years ago

Attachment: script.mos added

comment:2 by Adeel Asghar, 5 years ago

Component: OMEditNew Instantiation

comment:3 by Martin Sjölund, 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)
Last edited 5 years ago by Martin Sjölund (previous) (diff)

comment:4 by Per Östlund, 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 Francesco Casella, 5 years ago

Milestone: 1.14.01.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 Per Östlund, 5 years ago

Resolution: fixed
Status: assignedclosed

Fixed in 4cf73067 and b4fe245.

comment:7 by Francesco Casella, 5 years ago

Milestone: 1.15.01.14.0

Backported to 1.14.0

Note: See TracTickets for help on using tickets.