Frank Bergmann

An executable would only work if it would pick up libSBML from a shared library, so I could try. It is really odd that the static map would have already...

the object was not deleted, you saw in your stack trace, that there were no objects in side: ``` ◢ | mModelValues | { size=0 } ``` the bad ptr...

did you at the `std::atexit` handler as I asked? That way you can control that your stuff gets destroyed whenever you choose to, not when the runtime does. Most compilers...

well if whatever happened on the registry object destructor was moved into a function, that could be called `atexit` and would free stuff

ok, then try this patch too: ```diff diff --git a/src/sbml/extension/SBMLExtensionRegistry.cpp b/src/sbml/extension/SBMLExtensionRegistry.cpp index 1c20e7a20..283dcf768 100644 --- a/src/sbml/extension/SBMLExtensionRegistry.cpp +++ b/src/sbml/extension/SBMLExtensionRegistry.cpp @@ -50,6 +50,7 @@ #include #include +#include #ifdef __cplusplus @@ -75,6 +76,8...

very strange. Ok ... let's look at other things ... what converter / evaluate thingies are you calling that would use a map? anyway they could clean up after themselves...

indeed, thus my question what used the SBMLtransforms, in your case, so we could track and delete stuff there. anyways ... going again with the order of initialisation theory. it...

ok, can you please just add a `if (m == NULL) return;` at the top of `SBMLTransforms::getComponentValues` and try again? its just for testing right now anyways.

well, we either need an antimony-less test case in libsbml to sort this, or you tell me which converters / evaluations were called, so we can clean up the memory...

the deletion in the destructor tried to avoid the scenario where you have gazillions of documents processed and all still in memory. Clearly the converters called, should clear up their...