-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
c++ instances allocated via MemoryManager do not call destructors when deleted #1529
Comments
Thanks, we'll look into this and let you know. |
It looks like we might have just overlooked adding "alloc_type = TRICK_ALLOC_NEW" void* Trick::MemoryManager::declare_var(TRICK_TYPE type,std::string user_type_name, int n_stars, std::string var_name, int n_cdims, int *cdims); ,in MemoryManager_declare_var.cpp. I'll add this, and test to ensure that it works as intended. |
Specifically, my proposed fix is: After line 48, add: After lines 128 & 141, add: After line 158, add: |
that looks good to me |
Complication: It looks like the generated io_src allocation routines sometimes call calloc() [even when marked CPP], and sometimes call new(). Need to do more digging. |
hmm.. isn't there a io_src_*_destruct routine that gets generated? can't we use those? |
declare_var() should indicate in ALLOC_INFO::alloc_type, how it has allocated the new object. From this we know how to delete it. declare_var() can allocate an object in one of two ways: 1) using malloc or calloc, or 2) using io_src_alloc_<CLASS>, which is generated by ICG. PROBLEM 1 : ALLOC_INFO::alloc_type was not properly set when allocating a composite type. It should have been set to TRICK_ALLOC_NEW to indicate that it was allocated by io_src_alloc_<CLASS>. PROBLEM 2: The enumeration value TRICK_ALLOC_NEW is mis-named and is misleading. The io_src_alloc_<CLASS> routines do not necessarily allocate memory using new. If the object is a POD type, it uses calloc. SOLUTION: So, THIS commit: 1) Renames TRICK_ALLOC_NEW to TRICK_ALLOC_IOSRC so as not be misleading. 2) In declare_var(), sets alloc_type = TRICK_ALLOC_IOSRC when allocating a composite type (TRICK_STRUCTURED).
After interruptions, and complications, and mistakes, I believe I've finally got it. I've made a new pull-request (#1639) for which all of the unit tests pass. These include a new test ( TEST_F(MM_delete_var_unittest, CXX_object_constructor_destructor)) that specifically verifies that the destructor is being called. |
Similar to #1301 but for a different reason. I found that if I declare a c++ class using memory manager (i.e. TMM_declare_var_s for my specific test), the alloc_info instance that gets allocated to track it always has the allocation set for TRICK_ALLOC_MALLOC. Since that enum
TRICK_ALLOC_MALLOC = 0
, it's either a mistake and is just resulting to the default.. OR, allocations are intentionally tracked as MALLOC instead of TRICK_ALLOC_NEW for some reason. git grepping through the code, I see no attempt to set the alloc_type to anything except for the DataRecordGroup. So, it doesn't matter which API I use, Trick will never treat it as anything other than a malloc.The text was updated successfully, but these errors were encountered: