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

ESMF_RUNTIME_ environment variable to affect garbage collection behavior #277

Open
2 tasks done
theurich opened this issue Jul 31, 2024 Discussed in #269 · 0 comments
Open
2 tasks done

ESMF_RUNTIME_ environment variable to affect garbage collection behavior #277

theurich opened this issue Jul 31, 2024 Discussed in #269 · 0 comments
Assignees
Labels

Comments

@theurich
Copy link
Member

Currently some of the garbage collection code that runs during ESMF_Finalize() or ESMC_Finalize() is commented out. An idea that came out of the discussion #269 is to introduce a run-time environment variable ESMF_RUNTIME_GARBAGE_EMPTY, which if set would activate the currently commented out parts of the garbage collection code. This would allow running codes with full garbage collection enable to:

  • Ensure no memory leaks are present. Something that some codes want to test for.
  • Easily test situations for which the full garbage collection code is causing issues.

Discussed in https://github.com/orgs/esmf-org/discussions/269

Originally posted by AbhiHampiholi July 25, 2024

Requirements

Affiliation(s)

AirMettle, Inc

ESMF Version

8.6.0

Issue

Hello,
In my code, all the allocated ESMC objects are reported as memory leaks despite calling the ESMC destroy functions and the Finalize function at the end.
I noticed that the call to ESMC_GridDestroy calls the ESMCI::Grid::destroy(&gridp) which has signature static int destroy(Grid **grid, bool noGarbage=false); since no second argument is passed, the noGarbage flag is always false by default and inside the destroy function the delete is always skipped

  // optionally delete the complete object and remove from garbage collection
if (noGarbage){
  VM::rmObject(*gridArg); // remove object from garbage collection
  delete (*gridArg);      // completely delete the object, free heap
}

I've attached a reproducible example here (copied from the example @danrosen25 sent me yesterday) test_memleak.tar.gz

valgrind --leak-check=full ./exeMemLeak reveals the memory leaks. Let me know if I am missing something or if this is not-reproducible. If there isn't anything wrong with my setup, the fix might be to provide a way to set noGarbage=true while calling ESMCI::Grid::destroy() but I am not sure.

@theurich theurich added enhancement New feature or request source: discussions labels Jul 31, 2024
@anntsay anntsay assigned anntsay and theurich and unassigned anntsay Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants