Skip to content
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

Mystery of destroy flag in MemoryManager::delete_var. #1301

Open
jmpenn opened this issue Jul 8, 2022 · 5 comments
Open

Mystery of destroy flag in MemoryManager::delete_var. #1301

jmpenn opened this issue Jul 8, 2022 · 5 comments

Comments

@jmpenn
Copy link
Contributor

jmpenn commented Jul 8, 2022

THE PROBLEM
The purpose of the destroy flag in :
Trick::MemoryManager::delete_var(void* address, bool destroy ),
defined in MemoryManager_delete_var.cpp
is unclear (to both Alex and me). Apparently this is causing problems for some.

In MemoryManager_delete_var.cpp:

       if ( alloc_info->stcl == TRICK_LOCAL ) {
            if ( alloc_info->alloc_type == TRICK_ALLOC_MALLOC ) {
                if (destroy) {
                    io_src_destruct_class( alloc_info );
                }

If the MemoryManager performed the allocation, using malloc, and the destroy flag is set, then call io_src_destruct_class( alloc_info ), otherwise don't.

The question is why wouldn't you want to call io_src_destruct_class?

The only occurrence of a call to delete_var in the MemoryManager, with the destroy set to false is:
MemoryManager_clear_memory.cpp:

 delete_var( deletion_list[ii], false);

THE PLAN

The plan here is to simply change the call in MemoryManager_clear_memory.cpp from:

delete_var( deletion_list[ii], false);

to

delete_var( deletion_list[ii], true);

and see what happens.

From there we can better determine what we need to do about this issue.

@jmpenn
Copy link
Contributor Author

jmpenn commented Jul 8, 2022

If there are no ill effects from the change, then the destroy flag will be removed everywhere.

@spfennell
Copy link
Contributor

Is this a related issue possibly? #1037

@jmpenn
Copy link
Contributor Author

jmpenn commented Jul 8, 2022

Seems likely to me.

@jmpenn
Copy link
Contributor Author

jmpenn commented Jul 8, 2022

See new branch:
Issue_1301

% git diff MemoryManager_clear_memory.cpp
diff --git a/trick_source/sim_services/MemoryManager/MemoryManager_clear_memory.cpp b/trick_source/sim_services/MemoryManager/MemoryManager_clear_memory.cpp
index a71e1ffa..25e4939c 100644
--- a/trick_source/sim_services/MemoryManager/MemoryManager_clear_memory.cpp
+++ b/trick_source/sim_services/MemoryManager/MemoryManager_clear_memory.cpp
@@ -307,7 +307,7 @@ void Trick::MemoryManager::reset_memory() {
 
     n_addrs = deletion_list.size();
     for (ii = 0 ; ii < n_addrs ; ii ++) {
-        delete_var( deletion_list[ii], false);
+        delete_var( deletion_list[ii], true);
     }

@jmpenn
Copy link
Contributor Author

jmpenn commented Aug 30, 2022

I reopened this issue because SIM_splashdown now crashes with a SIGSEGV when attempting to reload a checkpoint.
When I revert the change, the checkpoint reloads normally.

With the change:
The SIGSEGV occurs in or shortly after io_src_destruct_Trick__RK4_Integrator.

Side Note: Finding the exact location of the SIGSEGV is difficult for a number of reasons including: the terminal is killed an instant after the SIGSEGV occurs.

By instrumenting ICG with messages, Iv'e been able to determine that the problem is occurring when called the integration class destructors.

When I configure Trick to NOT use the er7 utils integrators:

./configure --with-llvm=/Users/jpenn1/llvm13 --with-gtest=/usr/local --enable-er7utils=no

the problem doesn't happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants