32bit OMEdit unusable due to GC issues "Too Many Heap Section"

[Arno_Epsilon <acolleoni@…>]

I got blocker problems: if i open the tree of MSL, open a test example and try to run it (i did it with the filter example of block), i got "Too many heap sections".
I also have it sometimes when i am only navigating in the library tree.

Anyone have the same issue?

I got the problem with windows in the nightly builds 32bit versions from the 22nd to the 25th of april.

[Adrian Pop]

We are aware of this. I suggest you use the 64bit builds:
​https://build.openmodelica.org/omc/builds/windows/nightly-builds/

Are you forced to use 32bit OMC because of FMUs, external libs, or?

[Arno_Epsilon <acolleoni@…>]

Replying to adrpo:

We are aware of this. I suggest you use the 64bit builds:
​https://build.openmodelica.org/omc/builds/windows/nightly-builds/

Are you forced to use 32bit OMC because of FMUs, external libs, or?

Nope.
I just did not try the 64bit version.
Thx for the tip.

[Adrian Pop]

I will change this to "critical" as it should work fine with 64 bit.

[Rüdiger Franke]

Please consider this as blocker, because the Windows version is unusable for anyone who wants to export or import a 32 bit FMU. Model exchange is broken if OpenModelica export/import is upgraded to 64bit, while other import/export tools or previously exported FMUs stay with 32bit.

An exclusive 64 bit version of OpenModelica only works out if it ships with a 32 bit runtime.

[Alexander Täschner <A.Taeschner@…>]

For me this is also a blocker since I have to use the ExternalMedia library for Helium fluid simulations and this library is only compiled with 32 bit.

[Adrian Pop]

I think I have a fix for this, I will do some testing and hopefully push it in soon.

[Adrian Pop]

I investigated this more and it seem that the GC collector stops collecting after some time and OMEdit runs out of memory for a heap ~1G. Hopefully I'll find out why soon.

[Rüdiger Franke]

Alternatively to fixing this problem in the 32bit version, this ticket can also be fixed by bundling the 64bit versions of the tools (omc, OMEdit, ...) with 32bit versions of the runtimes.

This may even reduce the effort for the Windows build (only one version of the tools needed) and provide a first step towards cross compilation, i.e. bundle more than one runtime. See also #3950.

[Adrian Pop]

@rfranke: agreed that we should try to use 64bit always and cross-compile the 32bit libs. The problems with this is that it doesn't work on 32bit Windows and there are plenty of those still around.

However it seems the problem with GC is a bit more involved and has to do with dlls and globals and how these are shared with the main executable:

• libOpenModelicaCompiler.dll: links with static libomcgc.a
• OMEdit: links with static libomcgc.a and also dynamically with libOpenModelicaCompiler.dll and with libOpenModelicaRuntimeC.a which also is linked with static libomcgc.a

The globals from libomcgc.a should be shared by OMEdit and libOpenModelicaCompiler.dll but this doesn't seem to be the case even if I properly (as far as I can see) used:

• __declspec(dllimport) in OMEdit
• __declspec(dllexport) in libOpenModelicaCompiler.dll

Linux is straightforward, basically the globals are the same, Windows and Mac are always special.

[Adrian Pop]

This should be fixed by Boehm GC update:
​https://github.com/OpenModelica/OMCompiler-3rdParty/pull/13

[Adrian Pop]

Reopening as the situation has improved quite a bit but still not good enough.

[Adrian Pop]

Geez, the problem was that I forgot to add linker flag --large-address-aware to OMEdit compilation when we switched from msys/mingw to msys2/mingw32/mingw64. This flag was added to OMC that's why OMC did not have this issue.
This is now fixed in 4de915/OMEdit and a new 32bit build should work much better.

[Rüdiger Franke]

Looks much better now. Also the improved startup time makes a difference!

[Martin Sjölund]

Milestone deleted