Opened 10 years ago
Last modified 9 years ago
#3170 new defect
Under Mac OS X, BouncingBall FMU segfaults in fmuCheck
| Reported by: | Owned by: | somebody | |
|---|---|---|---|
| Priority: | high | Milestone: | Future |
| Component: | *unknown* | Version: | trunk |
| Keywords: | Cc: |
Description
Under Mac OS X, using the OpenModelica svn head from 20-Feb-2015, a BouncingBall FMU created with OpenModelica segfaults in fmuCheck.
See Ticket #3169 at https://trac.openmodelica.org/OpenModelica/ticket/3169 for setup.
Note that it is necessary to unzip the fmu in a tmp directory and do:
mv binaries/x86_64-apple-darwin13.4.0/ binaries/darwin64
zip -r ../BouncingBallFMI20.fmu *
I created a debug version of fmuCheck by editing FMUChecker-2.0.1/build/CMakeCache.txt and changing various places where optimization was used and -g was not used to -ggdb
//Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-ggdb //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-ggdb //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-ggdb //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-ggdb ... //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-ggdb //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-ggdb //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=-ggdb //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-ggdb
I also changed strip to touch
//Path to a program. CMAKE_STRIP:FILEPATH=touch
I then reran cmake .. and make, which gives me a debug version of fmuCheck.darwin64.
I still can't get a complete stack trace, but at least an assertion is failing:
bash-3.2$ ggdb /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.2.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64...done.
(gdb) r BouncingBallFMI20.fmu
Starting program: /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64 BouncingBallFMI20.fmu
[INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Feb 19 2015
[INFO][FMUCHK] Called with following options:
[INFO][FMUCHK] /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64 BouncingBallFMI20.fmu
[INFO][FMUCHK] Will process FMU BouncingBallFMI20.fmu
[INFO][FMILIB] XML specifies FMI standard version 2.0
Assertion failed: (index < a->size), function jm_vector_get_itemp_char, file /Users/cxh/src/fmi/FMUChecker-\
2.0.1/FMIL/src/Util/include/JM/jm_vector.h, line 352.
Program received signal SIGABRT, Aborted.
0x00007fff8af53866 in ?? ()
(gdb) where
#0 0x00007fff8af53866 in ?? ()
#1 0x00007fff8620935c in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb)
#0 0x00007fff8af53866 in ?? ()
#1 0x00007fff8620935c in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb)
Attachments (2)
Change History (5)
comment:1 by , 10 years ago
comment:2 by , 9 years ago
While tracking down some other issues, I realized that fmuCheck has logging which indicates that the error is after the FMU CAPI Interface is released:
bash-3.2$ cp ~/src/openmodelica/testsuite/openmodelica/fmi/ModelExchange/2.0/BouncingBall.mos .
bash-3.2$ /usr/local/openmodelica/bin/omc --version
v1.9.4-dev.721+g80e3e04
bash-3.2$ /usr/local/openmodelica/bin/omc BouncingBall.mos
true
""
"SimCode: The model BouncingBallFMI20 has been translated to FMU"
"Warning: The initial conditions are not fully specified. Use +d=initialization for more information.
"
"BouncingBallFMI20_me_FMU.mo"
""
true
""
record SimulationResult
resultFile = "/private/tmp/test/BouncingBallFMI20_me_FMU_res.mat",
simulationOptions = "startTime = 0.0, stopTime = 3.0, numberOfIntervals = 500, tolerance = 1e-06, method \
= 'dassl', fileNamePrefix = 'BouncingBallFMI20_me_FMU', options = '', outputFormat = 'mat', variableFilter = \
'.*', cflags = '', simflags = ''",
messages = "",
timeFrontend = 0.074107964,
timeBackend = 0.021939898,
timeSimCode = 0.011738527,
timeTemplates = 0.042531078,
timeCompile = 0.256368926,
timeSimulation = 0.066772791,
timeTotal = 0.474543105
end SimulationResult;
""
1.0
0.225020520707377
-0.9555208445822925
bash-3.2$ fmuCheck -l 6 BouncingBallFMI20.fmu
[VERBOSE][FMUCHK] Setting log level to [DEBUG]
...
[INFO][FMUCHK] Simulation finished successfully at time 1
[FMU][logFmi2Call][FMU status:OK] fmi2Terminate
[FMU][logFmi2Call][FMU status:OK] fmi2FreeInstance
[VERBOSE][FMUCHK] freeMemory(0x7f8f68700690) called
[VERBOSE][FMUCHK] freeMemory(0x7f8f68700880) called
[VERBOSE][FMUCHK] freeMemory(0x7f8f68700ab0) called
[VERBOSE][FMUCHK] freeMemory(0x7f8f68503180) called
[VERBOSE][FMUCHK] freeMemory(0x7f8f68501eb0) called
[VERBOSE][FMUCHK] freeMemory(0x7f8f68503150) called
[VERBOSE][FMUCHK] freeMemory(0x7f8f68503090) called
[VERBOSE][FMILIB] Releasing allocated library resources
[VERBOSE][FMILIB] Releasing FMU CAPI interface
Segmentation fault: 11
bash-3.2$
When I run fmuCheck using a handwritten FMU:
fmuCheck -l 6 $PTII/ptolemy/actor/lib/fmi/test/auto/bouncingBallME20.fmu
it ends with:
[INFO][FMUCHK] Simulation finished successfully at time 1
[FMU][logFmiCall][FMU status:OK] fmi2Terminate
[FMU][logFmiCall][FMU status:OK] fmi2FreeInstance
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01200) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01230) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01240) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01250) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01260) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01270) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01280) called
[VERBOSE][FMUCHK] freeMemory(0x7fa73be01160) called
[VERBOSE][FMILIB] Releasing allocated library resources
[VERBOSE][FMILIB] Releasing FMU CAPI interface
[VERBOSE][FMICAPI] Successfully unloaded FMU binary
[VERBOSE][JMPRT] Removing /private/tmp/fmucktmps1w4WN
FMU check summary:
FMU reported:
0 warning(s) and error(s)
Checker reported:
0 Warning(s)
0 Error(s)
bash-3.2$
gdb is not much help, I get:
bash-3.2$ ggdb /usr/local/bin/fmuCheck
GNU gdb (GDB) 7.9.1
...
(gdb) r -l 6 BouncingBallFMI20.fmu
r -l 6 BouncingBallFMI20.fmu
Starting program: /usr/local/bin/fmuCheck -l 6 BouncingBallFMI20.fmu
[VERBOSE][FMUCHK] Setting log level to [DEBUG]
[VERBOSE][FMUCHK] This binary is build without debug log messages.
Reconfigure with FMUCHK_ENABLE_LOG_LEVEL_DEBUG=ON and rebuild to enable debug level logging
[INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Feb 20 2015
[INFO][FMUCHK] Called with following options:
[INFO][FMUCHK] /usr/local/bin/fmuCheck -l 6 BouncingBallFMI20.fmu
[INFO][FMUCHK] Will process FMU BouncingBallFMI20.fmu
....
[INFO][FMUCHK] Simulation finished successfully at time 1
[FMU][logFmi2Call][FMU status:OK] fmi2Terminate
[FMU][logFmi2Call][FMU status:OK] fmi2FreeInstance
[VERBOSE][FMUCHK] freeMemory(0x1006062a0) called
[VERBOSE][FMUCHK] freeMemory(0x100606490) called
[VERBOSE][FMUCHK] freeMemory(0x1006066c0) called
[VERBOSE][FMUCHK] freeMemory(0x100600000) called
[VERBOSE][FMUCHK] freeMemory(0x1006045f0) called
[VERBOSE][FMUCHK] freeMemory(0x100602020) called
[VERBOSE][FMUCHK] freeMemory(0x100604530) called
[VERBOSE][FMILIB] Releasing allocated library resources
[VERBOSE][FMILIB] Releasing FMU CAPI interface
[New Thread 0x131b of process 41257]
[New Thread 0x1403 of process 41257]
[New Thread 0x1503 of process 41257]
[New Thread 0x1603 of process 41257]
[New Thread 0x1703 of process 41257]
[New Thread 0x1803 of process 41257]
[New Thread 0x1903 of process 41257]
Program received signal SIGSEGV, Segmentation fault.
0x00000001030c3080 in ?? ()
(gdb) where
#0 0x00000001030c3080 in ?? ()
#1 0x00007fff5fc01b3a in ?? ()
#2 0x00007fff5fc3f018 in ?? ()
#3 0x0000000100601c40 in ?? ()
#4 0x00007fff5fc3e8e8 in ?? ()
#5 0x0000000000000003 in ?? ()
#6 0x00007fff5fc3ef68 in ?? ()
#7 0x00007fff5fc27ac5 in ?? ()
#8 0x00007fff5fbfbac0 in ?? ()
#9 0x00007fff5fc04da8 in ?? ()
#10 0x00000001000b4000 in ?? ()
#11 0x000000000000c000 in ?? ()
#12 0x0000000103000000 in ?? ()
#13 0x000000000010d000 in ?? ()
#14 0x00000001000c5000 in ?? ()
#15 0x000000000001a000 in ?? ()
#16 0x00000001000e5000 in ?? ()
#17 0x000000000000f000 in ?? ()
#18 0x00000001000f9000 in ?? ()
#19 0x0000000000003000 in ?? ()
#20 0x000000010323e000 in ?? ()
#21 0x00000000001d3000 in ?? ()
#22 0x00000001034c0000 in ?? ()
#23 0x0000000000199000 in ?? ()
#24 0x0000000103668000 in ?? ()
#25 0x000000000011c000 in ?? ()
#26 0x000000010378b000 in ?? ()
#27 0x0000000000021000 in ?? ()
#28 0x00000001037af000 in ?? ()
#29 0x0000000000003000 in ?? ()
#30 0x00000001037b3000 in ?? ()
#31 0x000000000000a000 in ?? ()
#32 0x00000001037bf000 in ?? ()
#33 0x000000000000c000 in ?? ()
#34 0x00000001037cd000 in ?? ()
#35 0x000000000008d000 in ?? ()
#36 0x0000000103868000 in ?? ()
#37 0x000000000001e000 in ?? ()
#38 0x0000000103888000 in ?? ()
#39 0x00000000000f5000 in ?? ()
#40 0x0000000103989000 in ?? ()
#41 0x00000000000c8000 in ?? ()
#42 0x0000000103a6b000 in ?? ()
#43 0x00000000001d3000 in ?? ()
#44 0x0000000103cd6000 in ?? ()
#45 0x00000000000c6000 in ?? ()
#46 0x0000000103db5000 in ?? ()
#47 0x0000000000010000 in ?? ()
#48 0x0000000103dc9000 in ?? ()
#49 0x000000000002b000 in ?? ()
#50 0x0000000103f00000 in ?? ()
#51 0x0000000000118000 in ?? ()
#52 0x000000010407b000 in ?? ()
#53 0x0000000000037000 in ?? ()
#54 0x00000001040c0000 in ?? ()
#55 0x00000000000b8000 in ?? ()
#56 0x0000000104277000 in ?? ()
#57 0x0000000000016000 in ?? ()
#58 0x00007fff5fbfb570 in ?? ()
#59 0x00007fff5fc12482 in ?? ()
#60 0x00007fff98b45710 in dladdr () from /usr/lib/system/libdyld.dylib
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) info thread
info thread
Id Target Id Frame
8 Thread 0x1903 of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
7 Thread 0x1803 of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
6 Thread 0x1703 of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
5 Thread 0x1603 of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
4 Thread 0x1503 of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
3 Thread 0x1403 of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
2 Thread 0x131b of process 41257 0x00007fff8d4b1f5e in __psynch_cvwait ()
from /usr/lib/system/libsystem_kernel.dylib
* 1 Thread 0x1103 of process 41257 0x00000001030c3080 in ?? ()
(gdb)
I'm getting similar misbehaviour when I run using fmusdk2 from https://github.com/cxbrooks/fmusdk2, except gdb does not report that frame 60 is dladdr(). I'm not sure why, or what is up with that.
My guess is that closing the shared library is causing problems with OpenModelica fmus under Mac OS X.
comment:3 by , 9 years ago
It looks like if I unzip the .fmu file and run configure and then make, then fmuCheck no longer crashes.
This is under Mac OS X 10.11.1, (El Capitan) and with:
bash-3.2$ /usr/local/openmodelica/bin/omc --version v1.9.4-dev.721+g80e3e04
Built with
MY_FORK=MyGitHubUserName ; git clone https://openmodelica.org/git-readonly/OpenModelica.git --recursive && (cd OpenModelica && git remote set-url --push origin git@github.com:$MY_FORK/OpenModelica.git && git submodule foreach --recursive 'git remote set-url --push origin `git config --get remote.origin.url | sed s,^.*/,git@github.com:'$MY_FORK'/,`')
export CFLAGS=-I/opt/local/include
export LDFLAGS=-L/opt/local/lib
export PATH=/opt/local/libexec/qt4/bin:${PATH}
cd OpenModelica
autoconf
./configure --disable-omshell-terminal --disable-modelica3d --without-omc --prefix=/usr/local/openmodelica --without-paradiseo --disable-omnotebook --disable-python-interface --with-omniORB=/usr/local/omniORB-4.2.0 --with-lapack="-llapack -lblas
make omc
To replicate
cp ~/src/openmodelica/testsuite/openmodelica/fmi/ModelExchange/2.0/BouncingBall.mos . /usr/local/openmodelica/bin/omc BouncingBall.mos fmuCheck BouncingBallFMI20.fmu # The above segfaults at the end mkdir tmp cd tmp unzip ../BouncingBallFMI20.fmu cd sources ./configure make fmuCheck ../../BouncingBallFMI20.fmu # The above does not segfault at the end.
My best guess is that there is something in how omc builds the fmu vs. how configure builds the fmu. The build logs (attached before this bug) are slightly different.
Note:
See TracTickets
for help on using tickets.
I still can't get a stack trace, but here's how to build a debug version of FMUCheck-2.0.2b1 and a stack trace for the assert.
First, create /tmp/test/BouncingBallFMI20.fmu as per Ticket #3169.
Then, download the latest FMUCheck sources and build a debug version. Then run valgrind
The valgrind run looks like
The gdb output remains as above, there is no useful info.
BTW - one problem with the FMI code is that for more complex models, such as a heat conductor, the FMU invokes malloc using the Boehm GC, which causes problems for valgrind. I don't think that is the case here