#3465 closed defect (fixed)
Hudson fails with test Crane_FMU1_CPP
Reported by: | rfranke | Owned by: | adrpo |
---|---|---|---|
Priority: | high | Milestone: | 1.9.4 |
Component: | Testing Framework | Version: | |
Keywords: | Cc: | mwalther, sjoelund |
Description
Hudson produced twice the following error message that is hardly related my change on records (jobs 787, 788):
messages = "Simulation execution failed for model: cranes_crane_me_FMU module = FMICAPI, log level = FATAL: Could not load the DLL: /var/lib/hudson/slave/workspace/OpenModelica_TEST_PULL_REQUEST/OpenModelica/testsuite/openmodelica/cppruntime/fmu/modelExchange/1.0/Crane_FMU1_CPP.mos_temp3254/binaries/linux64/cranes_crane.so: undefined symbol: _ZN13StatArrayDim2IdLm3ELm3ELb0EEclEmm
c++filt -n:
StatArrayDim2<double, 3ul, 3ul, false>::operator()(unsigned long, unsigned long)
The operator()(size_t, size_t) finds in the file Array.h. The test succeeds on my development machine.
I disabled it temporarily and added an alternative simple FMI 1.0 test.
Change History (7)
comment:1 Changed 9 years ago by mwalther
comment:2 Changed 9 years ago by mwalther
The issue is really strange. It occurs in the functions-class of the model. In more detail it occurs inside the function "Modelica_Mechanics_MultiBody_Frames_resolve2", which uses a reference to a custom type that contains the array-class.
The strange thing is that this function is never called and the custom type is not used. This seems to produce some trouble. If I add a line to the model class to create an instance of the custom type, the error disappears.
comment:3 Changed 9 years ago by mwalther
We now create a dummy variable for each custom type which is defined in the types-class (see OMCompiler - 2fa610a1e). This happens during initialization and will fix the linker error. The crane models are part of the testsuite again. The pull request job including the changes (829) succeeded, so I think we can close the ticket.
comment:4 Changed 9 years ago by mwalther
- Resolution set to fixed
- Status changed from new to closed
comment:5 Changed 9 years ago by dietmarw
- Milestone changed from Future to 1.9.4
Sorting these closed tickets away from "Future". Since they were closed after the last 1.9.3 release, it's very likely that they should have been part of the 1.9.4 release.
comment:6 Changed 8 years ago by sjoelund.se
- Milestone changed from 1.9.4 to 1.9.4-1.9.x
Milestone renamed
comment:7 Changed 8 years ago by sjoelund.se
- Milestone changed from 1.9.4-1.9.x to 1.9.4
Milestone renamed
A similar error occurs with MinGW as well, so it seems to be a GCC 4.4 related issue.