Home › Forum › SOFA › Programming with SOFA › [SOLVED] Memory problems in simple app using Sofa as lib
Tagged: 64_bits, SOFA_other, Windows_10
- This topic has 3 replies, 3 voices, and was last updated 8 years, 6 months ago by Matthieu Nesme.
-
AuthorPosts
-
29 March 2016 at 09:41 #6385Alex BilgerBlocked
Hello guys,
I have a problem with smart pointers which appear not to be as smart as we want. I have this problem in the simplest application using Sofa as a library. I use a CMakeLists file to link Sofa to my app. In the app, I wrote a simple scene with only one root node, in which I add a Mechanical Object. Other implicit objects are created, but I don’t add them myself.
The compilation went well. However, the app crashes when dealing with the SPtr object of the mechanical object. I had the problem of creating it (in a different context), but here I have problems when destroying it. At the end of the scope, the SPtr object is destroyed, the mechanical object should be deleted. The apps crashes in this delete:
void Base::release() { if (ref_counter.dec_and_test_null()) { delete this; //crashes here!!! } }
This problem does not occur in runSofa. I also wrote a minimal sofa project (in applications/project), and don’t have the problem neither. Do you think it’s related to the way I link Sofa? In this case, could you describe how I should do it? I hope this conversation could also be a start for the documentation of this page: https://www.sofa-framework.org/support/doc/programming-with-sofa/write-a-scene-in-c/ and another describing how to use sofa as a lib.
The CMakeLists I use: http://pastebin.com/KCt0PhSa
I use Windows 10, 64 bits with MSVC 18 to compile. Sofa and the app are compiled in Debug mode. Sofa is compiled from the Git sources.Thanks for helping
Alex
30 March 2016 at 16:41 #6409Alex BilgerBlockedWe finally found that it does not crash only if the preprocessor variable SOFA_USE_MASK is defined. It’s the case by default in the Sofa projects, but not if we create an independent project from scratch. I recommend to change this behavior or to notice it in a documentation.
Thanks a lot if you started working on this problem
30 March 2016 at 18:21 #6410HugoKeymasterThank you Alex for this quick analysis of the problem.
The mask (and the associated issue here) is a work that we intend to address in the coming months. We’ll take care of it.Cheers,
Hugo
14 June 2016 at 10:43 #7097Matthieu NesmeBlockedSorry for my late answer, but I guess the problem has nothing to do with the masks.
And I would recommend you to use the masks!It comes from which compilation variables where defined while compiling SOFA and which one are defined when including sofa headers in your external application.
By default SOFA_USE_MASK is defined while compiling sofa, so every header files with #ifdef SOFA_USE_MASK will do some specific stuff, if you do not define the SOFA_USE_MASK variable before including the header, it cannot work.
Of course this is true for any compiler variables.
There are several possibilities to make it transparent for someone who want to use SOFA as an external library, and we have to put something in place. -
AuthorPosts
- You must be logged in to reply to this topic.