You are here

My model crashes Simile (MacOS X)

Hi all,

has anyone experienced that a complicated model can crash
the Simile execution window?
I am currently evaluating whether I can overcome these problems (and become a happy license owner), or have to move my model to something else, so any experiences would be appreciated, particularly as I really like Simile. The model is too big to debug as Tcl.

This happens on the 4.3GM as well as the 4.4 version for Mac OS X 10.4, and it is reproducable. What happens is that the execution window (the secondary one that pops up after one chooses to run or debug a model) suddenly disappears, and the main application is stuck.

I put the model, the configuration file, and the parameter csv spreadsheet
file that relates to the parameter orbitetp here:

http://www.soes.soton.ac.uk/staff/heiko/wkdi4.sml
http://www.soes.soton.ac.uk/staff/heiko/wkdi4.shf
http://www.soes.soton.ac.uk/staff/heiko/wkdi4.csv

A screenshot of the crashed window (prevented from disappearing
by gdb) is at

http://www.soes.soton.ac.uk/staff/heiko/crashed_screenshot.png

For those in the know, there appear to be 3 processes running,
and in this case it is process 15026 (the first one in the list below) crashing.
The gdb backtrace is also attached below. At the time of the crash, it
uses about 180MB of memory:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
15026 Simile 0.0% 3:11.34 5 108 2558 172M 32.9M 186M 2.00G

Also, has anyone experienced a different type of crash occurring if one tries to read in a large csv file into a table? The error code mentions
a stack overflow relating to "GLOBALSZ" that appears to be related to
the builtin Prolog environment within xgsimile. This problem happens already with some quite small tables.

Many thanks & happy modelling,
Heiko

heiko 15026 100.3 -4.4 1019812 91868 ?? RX 7:28PM 0:43.51 ../../MacOS/Simile ../Run/runmodel.tcl node00000 /Users/heiko/Simile/sim68 send Simile pipe get_data
heiko 15008 0.0 -1.1 398284 22172 ?? S 7:26PM 0:17.50 /Applications/Simile4.4.app/Contents/MacOS/Simile -psn_0_14155777
heiko 15010 0.0 -1.2 533560 25448 ?? S 7:26PM 0:38.83 /Applications/Simile4.4.app/Contents/Resources/Scripts/../Run/xgsimile

[246-11:Contents/Resources/Run] heiko% gdb
GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin".
(gdb) attach 15026
Attaching to process 15026.
Reading symbols for shared libraries . done
Reading symbols for shared libraries .................................................................................................... done
0x90003d90 in szone_malloc ()
(gdb) cont
Continuing.

Program received signal SIGABRT, Aborted.
0x9004a12c in kill ()
(gdb) bt
#0 0x9004a12c in kill ()
#1 0x90120954 in abort ()
#2 0x9547dd50 in __gnu_cxx::__verbose_terminate_handler ()
#3 0x9547ba54 in __cxxabiv1::__terminate ()
#4 0x9547bab8 in std::terminate ()
#5 0x9547af90 in __cxa_get_globals ()
#6 0x9547bd9c in __cxa_current_exception_type ()
#7 0x9547dd5c in __gnu_cxx::__verbose_terminate_handler ()
#8 0x9547ba54 in __cxxabiv1::__terminate ()
#9 0x9547bab8 in std::terminate ()
#10 0x9547af90 in __cxa_get_globals ()
#11 0x9547bcf4 in __cxa_throw ()
#12 0x9549bca8 in operator new ()
#13 0x9549bdac in operator new[] ()
#14 0x05fc4aa0 in collect ()
#15 0x05fc5d38 in AME_model::int_evalmodel ()
#16 0x05fc2c40 in do_evalmodel ()
#17 0x017bb814 in Model::rk_update ()
#18 0x017bb260 in Model::executemodel ()
#19 0x017b2c74 in execute ()
#20 0x0179d474 in executemodelCmd ()
#21 0x0a00eb00 in TclEvalObjvInternal ()
#22 0x0a0325ac in TclExecuteByteCode ()
#23 0x0a031bb0 in TclCompEvalObj ()
#24 0x0a0619dc in TclObjInterpProc ()
#25 0x0a00eb00 in TclEvalObjvInternal ()
#26 0x0a0325ac in TclExecuteByteCode ()
#27 0x0a031bb0 in TclCompEvalObj ()
#28 0x0a0619dc in TclObjInterpProc ()
#29 0x0a00eb00 in TclEvalObjvInternal ()
#30 0x0a0325ac in TclExecuteByteCode ()
#31 0x0a031bb0 in TclCompEvalObj ()
#32 0x0a0619dc in TclObjInterpProc ()
#33 0x0a00eb00 in TclEvalObjvInternal ()
#34 0x0a0325ac in TclExecuteByteCode ()
#35 0x0a031bb0 in TclCompEvalObj ()
#36 0x0a00f908 in Tcl_EvalObjEx ()
#37 0x01564590 in WidgetEnsembleCommand ()
#38 0x01564608 in WidgetEnsembleCommand ()
#39 0x0a00eb00 in TclEvalObjvInternal ()
#40 0x0a0325ac in TclExecuteByteCode ()
#41 0x0a031bb0 in TclCompEvalObj ()
#42 0x0a00f908 in Tcl_EvalObjEx ()
#43 0x01565590 in WidgetInstateCommand ()
#44 0x01564590 in WidgetEnsembleCommand ()
#45 0x01564608 in WidgetEnsembleCommand ()
#46 0x0a00eb00 in TclEvalObjvInternal ()
#47 0x0a00f3b0 in Tcl_EvalEx ()
#48 0x0a00f6e8 in Tcl_Eval ()
#49 0x0a010e4c in Tcl_GlobalEval ()
#50 0x0b003780 in Tk_BindEvent ()
#51 0x0b0212b8 in TkBindEventProc ()
#52 0x0b02c4c4 in Tk_HandleEvent ()
#53 0x0b02c9b0 in WindowEventProc ()
#54 0x0a057574 in Tcl_ServiceEvent ()
#55 0x0a057944 in Tcl_DoOneEvent ()
#56 0x0b02ca38 in Tk_MainLoop ()
#57 0x0b04ab54 in Tk_MainEx ()
#58 0x00010094 in main ()
(gdb)

Forums: 

Wow, this looks like serious science!

I can see where the problem is -- there appears to be a memory leak involved in collecting values for variable parameters. As the model runs, it overgrows all the system's memory and eventually crashes.

We'll get this fixed before the next release. In the mean time, here's a complicated workaround: if you actually want to set these parameters interactively while the model runs, put them into a submodel and get it to run on a longer time step than the rest of the model. To do this, set the time step index of the desktop to 2 and that of the parameters submodel to 1, then when runnong the model, set time step 2 to 0.5 (the current time step) and step 1 to about 100. Longer time steps have to have lower indices. Simile will then read slider values less often, and the memory usage will not run away so quickly.

Sorry about this, but look forward to a fix soon.

--Jasper

Actually you might want to patch your copy of Simile. Just apply the following patch to support1.cpp in the Run directory (under Contents/Resources on the Mac)

142c142
---
> int curIndices[32];
145d144

...and edit your model so Simile builds a new executable for it, and the problem should be fixed.
--J

Many thanks, very helpful indeed!

I'll try out both options and report back.

Cheers,
Heiko

Many thanks indeed,

the proposed patch seems to have fixed it!
Cheers,
Heiko

Hello again...I had a bit more of a fiddle with the model you put up here, and I think I need to give you a hint: if you use submodels to divide your model into functional blocks, Simile's model editor will have a faster response. This is because it only searches in the current submodel for related items when editing the graphics.

--Jasper