Opened 6 years ago

Closed 6 years ago

#5102 closed defect (fixed)

FMU Memory Issue (Segfault when simulating)

Reported by: anonymous Owned by: Lennart Ochel
Priority: high Milestone: Future
Component: FMI Version: v1.12.0
Keywords: Cc:

Description

Likely related to #4135

I am doing a parameter estimation on an FMU generated by OM. This parameter estimation is performed by PyFMI (Original Issue Logged with PyFMI: https://github.com/modelon/PyFMI/issues/7). If I run a large enough estimation (long simulation duration or numerous params to be simulated), I will encounter a segfault.

The PyFMI dev suspects it's a memory issue with the generated FMU.

I can't get the FMU Compliance Checker to trigger a segfault.

I ran the PyFMI script inside gdb and printed out a backtrace of the fault :

Program received signal SIGSEGV, Segmentation fault.
0x00007fffd862fbdf in pool_malloc.lto_priv ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
(gdb) Quit
(gdb) bt
#0  0x00007fffd862fbdf in pool_malloc.lto_priv ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#1  0x00007fffd86422b2 in mmc_mk_scon.lto_priv ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#2  0x00007fffd8631167 in modelica_string_format_to_c_string_format ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#3  0x00007fffd8631180 in modelica_real_to_modelica_string_format ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#4  0x00007fffd863cdcd in Test_eqFunction_49 ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#5  0x00007fffd863d2c2 in Test_updateBoundParameters ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#6  0x00007fffd86461ae in initialization ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#7  0x00007fffd863eace in fmi2EnterInitializationMode ()
   from /tmp/luke/JModelica.org/jm_tmpjW_YQw/binaries/linux64/Test.so
#8  0x00007fffe4122b4e in __pyx_pf_5pyfmi_3fmi_13FMUModelBase2_34enter_initialization_mode (__pyx_v_self=0x5555570b8300) at src/pyfmi/fmi.c:46575
#9  __pyx_pw_5pyfmi_3fmi_13FMUModelBase2_35enter_initialization_mode (
    __pyx_v_self=0x5555570b8300, unused=<optimised out>)
    at src/pyfmi/fmi.c:46512
#10 0x00007fffe4067a30 in __Pyx_PyObject_CallMethO (arg=0x0, 
    func=0x7fffd3f047a0) at src/pyfmi/fmi.c:96058

Change History (3)

comment:1 by anonymous, 6 years ago

Still occurs on the latest Nightly build (1.13.0-dev)
This build includes the suggested fix in the related issue #4135:

The same trouble with the FMUs (pendulum1 and pendulum2) in
the "FmuFmuPendulumInternalDynamics" model which is included
in the examples of composite model for OMTLMSimulator.

As it is tested in linux64 system, there is a segfault in
mmc_mk_scon() to set the string constants in the routine
to assign the initial condition.

After some maze running, I found that pool_malloc() is called without
initialization of the memory pools.
So, as an ad-hoc remedy, one can modify pool_exapnd() just adding a line to initialize the pools.

Dose it help?

static inline void pool_expand(size_t len)
{
  list *newlist = NULL;
  /* Check if we have enough memory already */
  if (memory_pools == NULL) pool_init(); // <-- this line !!!!
  if (memory_pools->size - memory_pools->used >= len) {
    return;
  }
  newlist = (list*) malloc(sizeof(list));
  memory_pools = newlist;
  memory_pools->used = 0;
  memory_pools->size = upper_power_of_two(3*memory_pools->next->size/2 + len); /* expand by 1.5x the old memory pool. More if we request a very large array. */
  memory_pools->memory = malloc(memory_pools->size);

}



comment:2 by Francesco Casella, 6 years ago

You report the issue with the stable version 1.12.0. Please try the latest nightly build, as soon as it is back online (see #5068) and check if the issue is still there.

in reply to:  2 comment:3 by luke-dempsey@…, 6 years ago

Resolution: fixed
Status: newclosed

Replying to casella:

You report the issue with the stable version 1.12.0. Please try the latest nightly build, as soon as it is back online (see #5068) and check if the issue is still there.

(OP): New nightly build (1.13.0~dev-1371-gc7f4444-1) fixes this issue (so far), thanks @casella!

Note: See TracTickets for help on using tickets.