-
Notifications
You must be signed in to change notification settings - Fork 95
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
Remove memory leaks #186
base: rolling
Are you sure you want to change the base?
Remove memory leaks #186
Conversation
unloadLibraryInternal(false); | ||
} | ||
if (remove_when_possible) { | ||
delete this; |
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.
@ahcorde this is very unusual. I'd suggest we use an std::shared_ptr
to track ClassLoader
ownership and defer cleanup tasks to its destructor.
@@ -169,6 +169,7 @@ class ClassLoader | |||
template<class Base> | |||
Base * createUnmanagedInstance(const std::string & derived_class_name) | |||
{ | |||
class_loader_ref_count--; |
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.
@ahcorde to compensate for the ref count increase in createRawInstance
? What if a plugin is simultaneously deleted? I'd strongly suggest not creating these glitches in the ref count.
@@ -545,6 +545,7 @@ void unloadLibrary(const std::string & library_path, ClassLoader * loader) | |||
", keeping library %s open.", | |||
library_path.c_str()); | |||
} | |||
purgeGraveyardOfMetaobjects(library_path, loader, true); |
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.
@ahcorde hmm, I think this was not here on purpose:
class_loader/src/class_loader_core.cpp
Lines 235 to 242 in 7b03fe3
// Insert into graveyard | |
// We remove the metaobject from its factory map, but we don't destroy it...instead it | |
// saved to a "graveyard" to the side. | |
// This is due to our static global variable initialization problem that causes factories | |
// to not be registered when a library is closed and then reopened. | |
// This is because it's truly not closed due to the use of global symbol binding i.e. | |
// calling dlopen with RTLD_GLOBAL instead of RTLD_LOCAL. | |
// We require using the former as the which is required to support RTTI |
But I wonder why
class_loader/test/unique_ptr_test.cpp
Line 174 in 471c398
TEST(ClassLoaderUniquePtrTest, loadRefCountingLazy) { |
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.
What about this @ahcorde ?
Signed-off-by: ahcorde <[email protected]>
Signed-off-by: ahcorde <[email protected]>
Signed-off-by: ahcorde <[email protected]>
Signed-off-by: ahcorde <[email protected]>
Signed-off-by: ahcorde <[email protected]>
563ef2b
to
6ced46e
Compare
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.
Once comments are addressed and CI goes green, I'm onboard with the change.
Signed-off-by: ahcorde <[email protected]>
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.
uncrustify
is angry again
Signed-off-by: ahcorde <[email protected]>
Signed-off-by: ahcorde <[email protected]>
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.
@ahcorde LGTM but for a question. Also, we should probably open a ticket to come back after Humble and remove the raw pointer interface.
* This class inherit from enable_shared_from_this which means we must used smart pointers, | ||
* otherwise the code might work but it may run into a leak. |
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.
@ahcorde nit:
* This class inherit from enable_shared_from_this which means we must used smart pointers, | |
* otherwise the code might work but it may run into a leak. | |
* This class inherits from `std::enable_shared_from_this`. It should be instantiated using an `std::shared_ptr`. | |
* Code will otherwise work but memory may be leaked. |
@@ -545,6 +545,7 @@ void unloadLibrary(const std::string & library_path, ClassLoader * loader) | |||
", keeping library %s open.", | |||
library_path.c_str()); | |||
} | |||
purgeGraveyardOfMetaobjects(library_path, loader, true); |
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.
What about this @ahcorde ?
for (unsigned int i = 0; i < impl_->associated_class_loaders_.size(); i++) { | ||
delete impl_->associated_class_loaders_[i]; | ||
} |
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.
I don't understand how this doesn't cause problems unless these AbstractMetaObjectBase are never destroyed while the program is running?
Are these not the same ClassLoaders you are storing in shared_ptr objects?
Signed-off-by: ahcorde [email protected]
I ran class_loader with asan and I found some memory leaks.
There is still one memory leak when we create unmanaged instance, the way to reproduce this leak is to run
basicLoadUnmanaged
andnoWarningOnLazyLoad
tests at the same time.what is the right way to destroy this memory ?