Ability to pass options to the underlying engine to prevent "Cannot enlarge memory arrays"?

[rodinhart]

I am trying to visualise a fairly sizable statechart (maybe 50 states, with 7 levels deep nesting), but get an error when going beyond level 5.

Expected Behavior

Expect the SVG to be produced.

Current Behavior

abort("Cannot enlarge memory arrays. Either
(1) compile with -s TOTAL_MEMORY=X with X higher than the current value 16777216,
(2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows increasing the size at runtime but prevents some optimizations,
(3) set Module.TOTAL_MEMORY to a higher value before the program runs, or
(4) if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0 "). 
Build with -s ASSERTIONS=1 for more info.

Possible Solution

Increase allocated memory, or provide more detailed error logging why it runs out? Perhaps a small tweak to the statechart will prevent the engine from choking?

Steps to Reproduce (for bugs)

Context

I'm just trying to find a good visualizer for our statechart, most importantly one that is stable (in its layout).

Your Environment

• Version used: 4.1.0
• Node version: 8.12.0
• Operating System and version: Windows 10
• Link to your project:

[sverweij]

hi @rodinhart - below the waterline state-machine-cat uses viz.js (which is graphviz, compiled to javascript) by default for generate the svg. it's viz.js that emits this error message.

• Using another layout algorithm ('engine') might help. For hierarchical state machines, apart from the default dot one, fdp (which should be better suited for bigger graphs) and osage algorithms work:

  smcat --engine fdp yourstatemachine.smcat

  or

  smcat --engine osage yourstatemachine.smcat

  You can also play around with these in the hamburger menu on the demo website (https://state-machine-cat.js.org)

• Another workaround could be to use the 'native' graphviz

  smcat --output-type dot yourstatemachine.smcat | dot -T svg > yourstatemachine.svg

• (the native graphviz is usually compiled with support for fdp and sometimes with osage support as well - replace dot -T svg above with dot -T svg -Kfdp to try it in the native version)
• For the longer run I'm looking at rendering engines different from graphviz that have the same/ similar features but a lower memory footprint.
• There's a newer version of viz.js than the one state-machine-cat currently uses that might solve this issue. When I took it for a test run it leaked memory though - I'll have a look again and see if I can include that in a next version.

I agree b.t.w. about the (lack of) clarity of the error message - I'll see if I can at least put some context to it before passing it on to output.

=> I'm b.t.w. very interested in sizeable (and big / humongous) charts to include them in my automated tests. I'll understand if you can't share your state machine description - but if you can it would be helpful (and maybe I can tweak something in the dot state-machine-cat generates so it does work when I have a real life sample...)

[rodinhart]

Hallo @sverweij , thank you for the extensive response! My response to your response in order:

I will try the different layouts and see how they do. The default dot is definitely the one that I'm after, as it seems the clearest, and closest to Harel's diagrams.

I will definitely try using graphviz directly, this will hopefully allow me to tweak a few things which would be perfect.

Re low memory replacement for graphviz: understood, I appreciate the difficulty of putting something appropriate in place.

Re new version of viz.js. Also understood, we've all been there.

Finally, I will try to get an anonymized version of the statechart to you for testing purposes.

Thanks again.

[sverweij]

FYI: I've made a minimal reproduction sample - it seems the nesting depth is quite memory intensive for the dot algorithm. fdp and osage handle it better. They also yield nicer looking diagrams (see below - for smaller/ less deeply nested diagrams this is not typically true...)

• An anonymised version of your state chart is still super welcome!!
• My suggestion to use the native graphviz dot will help a bit, but it will croak at some point as well - my guess is that for your chart it won't be an improvement (look what it does to the 11 states below ...)
• I've tried to tweak the intermediate dot format, but wasn't able to make viz.js (or the native gv for bigger graphs) happy yet - but I do have one or two tricks that could work ...

a {
    aa {
        aaa {
            aaaa {
                aaaaa {
                    aaaaaa {
                        aaaaaaa {
                            aaaaaaaa {
                                aaaaaaaaa => aaaaaaaab;
                                aaaaaaaaa => aaaaaaaac;
                                aaaaaaaac => aaaaaaaad;
                            }; 
                        };
                    };
                };
            };
        };
    };
};

osage

fdp

dot

😬

[rodinhart]

Brilliant!

_statemachine.txt

Both fdo and osaga manage to produce a chart, but in my case a lot of the transition go wildly across the diagram. Also, some transition meet not at the edge of a node, but somewhere in white-space. dot seems to be better suited (if we can get it to run).

I still want to try graphviz directly, just to see what happens.

[rodinhart]

graphviz works!

[sverweij]

thanks for the _statemachine.txt - helpfull!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.