-
Notifications
You must be signed in to change notification settings - Fork 903
fix some memleak #13306
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
base: main
Are you sure you want to change the base?
fix some memleak #13306
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -90,7 +90,7 @@ static int opal_patcher_base_close(void) | |
return opal_patcher->patch_fini(); | ||
} | ||
|
||
return OPAL_SUCCESS; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am really vary skeptical about this change. While logically it sounds reasonable, the patcher is a very special module, it changes the way the memory allocations/deallocations are tracked, and I'm definitively not sure we can unload it. I personally would be against this change without proper testing, but I defer to others for additional insights. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It just release component resources, and patch_list has been released in line 86. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's exactly my concern. The patcher works by interposition, aka. it interposes functions calls to sbrk or similar API. If the shared library where these functions are defined runs out of scope and is unloaded, bad things will happen (as it will call a function in a memory area that has been release and possibly reused). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @hjelmn is the one that should really chime in on this. Looking at the code, all the right bits are there such that unloading the component should work. But clearly we're not testing it. |
||
return mca_base_framework_components_close(&opal_patcher_base_framework, NULL); | ||
} | ||
|
||
/* Use default register/open functions */ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is correct, the module is already retained once for each function used (during
*_enable
).