Segmentation fault when Simulate is called with non-existent argument (stepSize)

[anonymous]

​https://build.openmodelica.org/Documentation/OpenModelica.Scripting.simulate.html

The above link shows that for "Simulate" function can have "stepSize" argument. Although the

function declaration does not have a corresponding input line.

My earlier simulations used to work with this argument. Looks as though in the new commits this argument is no longer present in builtin function "simulate".

But what surprised me was that the simulation call failed with segmentation fault. I would have thought supplying non existent argument would be caught at parsing stage. Perhaps it is not possible to catch such errors with builtin functions :((.

Is there a way to make it easy to trace such problems?

Error trace dumped on terminal after simulate call

Limited backtrace at point of segmentation fault
/lib64/libpthread.so.0[0x35ca60f6d0]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Expression_traverseExp+0x1855)[0x7f5da8c469f5]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Expression_traverseExpList+0x67)[0x7f5da8c47b17]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Expression_traverseExp+0x11c6)[0x7f5da8c46366]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_ExpressionSimplify_simplify1FixP+0x195)[0x7f5da8c21d75]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_ExpressionSimplify_simplify1WithOptions+0x2f)[0x7f5da8c2211f]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_ExpressionSimplify_simplify1+0x19)[0x7f5da8c221a9]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_StaticScript_elabExp2+0x2ed)[0x7f5da87617fd]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_StaticScript_elabExp+0xa7)[0x7f5da8761a07]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Interactive_evaluateAlgStmt+0xc3e)[0x7f5da8759eee]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Interactive_evaluate2+0x17d)[0x7f5da875badd]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Interactive_evaluateToStdOut+0x24e)[0x7f5da875c5ce]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Main_translateFile+0x3bd)[0x7f5da836baad]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Main_main2+0x3e7)[0x7f5da836d3d7]
/home/ravi/software/om/bin/../lib/omc/libOpenModelicaCompiler.so(omc_Main_main+0x17b)[0x7f5da836d6ab]
Segmentation fault (core dumped)

[Per Östlund]

I've updated the documentation to reflect that simulate doesn't have stepSize anymore. But I can't replicate the segfault you get. I tried to just call simulate(someModel, stepSize = 0.2), and it worked fine. Obviously we should check the arguments and disallow this, but at the moment it should just ignore any invalid arguments.

Have you built OMC yourself? If so, try to rebuild everything if your current build wasn't from a clean trunk. If that doesn't work, build the compiler without optimizations and run it in gdb:

$ CFLAGS="-g -O0" ./configure [any options you use]
$ make clean && make omc
$ gdb omc
(gdb) set args /path/to/your/mos_script.mos
(gdb) run

Then when it segfaults, copy the shown stack frame and paste it here. That should be all I need to find the issue if it's just an undefined variable in the compiler.

If you haven't built OMC yourself and don't want to, then I would need some more information about exactly how you are calling simulate so I can try to replicate the issue myself.

[Ravi Saripalli <ravi.saripalli@…>]

I compiled omc myself with default CFLAGS. I will debug the way you suggested once you try this simple example code at your end and let me know the outcome. Thank you for your prompt response.

[Per Östlund]

Replying to Ravi Saripalli <ravi.saripalli@…>:

I compiled omc myself with default CFLAGS. I will debug the way you suggested once you try this simple example code at your end and let me know the outcome. Thank you for your prompt response.

Ok, it seems like the issue can be summed up like this:

step_size := 0.05;
simulate(..., stepSize = step_size);

I.e. binding a non-existing argument to a variable causes a segmentation fault for some reason. I will investigate and see what the problem is.

[Ravi Saripalli <ravi.saripalli@…>]

Here is the debug info for this problem

(gdb) run
Starting program: /home/ravi/software/om/bin/omc /home/ravi/DSTO/projects/Om/testing/PIController/plant.mos
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff457b700 (LWP 3489)]
[New Thread 0x7ffff3d7a700 (LWP 3490)]
[New Thread 0x7ffff3579700 (LWP 3491)]
[New Thread 0x7ffff2d78700 (LWP 3492)]
[New Thread 0x7ffff2577700 (LWP 3493)]
[New Thread 0x7ffff1d76700 (LWP 3494)]
[New Thread 0x7ffff1575700 (LWP 3495)]
Plant Model Loaded
Cleaning Up Work Area
Detaching after fork from child process 3496.
rm: cannot remove 'work/*': No such file or directory
Compile command: g++
Temp folder path: /tmp
Installation folder: /home/ravi/software/om
Modelica path: /home/ravi/software/om/lib/omlibrary
Simulation has begun
true

'''Program received signal SIGSEGV, Segmentation fault.
0x00007ffff58faf91 in mmc_prim_get_real (p=0x0)
    at /home/ravi/software/om/src/build/include/omc/c/meta/meta_modelica.h:309
309	  u.data[0] = *data;'''
(gdb) 

Replying to perost:

Replying to Ravi Saripalli <ravi.saripalli@…>:

I compiled omc myself with default CFLAGS. I will debug the way you suggested once you try this simple example code at your end and let me know the outcome. Thank you for your prompt response.

Ok, it seems like the issue can be summed up like this:

step_size := 0.05;
simulate(..., stepSize = step_size);

I.e. binding a non-existing argument to a variable causes a segmentation fault for some reason. I will investigate and see what the problem is.

[Per Östlund]

This should be fixed in r23801.

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.