You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR is to address the memory leak about the meta-object is not destroyed during a process exit if using ClassLoader.
memory leak log
chenlh test $ valgrind --leak-check=full ./class_loader_unique_ptr_test --gtest_filter="*.basicLoad"
==63164== Memcheck, a memory error detector
==63164== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==63164== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info==63164== Command: ./class_loader_unique_ptr_test --gtest_filter=*.basicLoad==63164== Note: Google Test filter = *.basicLoad[==========] Running 1 test from 1 test suite.[----------] Global test environment set-up.[----------] 1 test from ClassLoaderUniquePtrTest[ RUN ] ClassLoaderUniquePtrTest.basicLoadMeow************************************************************************************ class_loader impl DEBUG INFORMATION ************************************************************************************OPEN LIBRARIES IN MEMORY:--------------------------------------------------------------------------------Open library 0 = libclass_loader_TestPlugins1.so (handle = 0x4ede240)METAOBJECTS (i.e. FACTORIES) IN MEMORY:--------------------------------------------------------------------------------Metaobject 0 (ptr = 0x4edf050): TypeId = N12class_loader4impl10MetaObjectI3Cat4BaseEE Associated Library = libclass_loader_TestPlugins1.so Associated Loader 0 = 0x1ffeff8000--------------------------------------------------------------------------------Metaobject 1 (ptr = 0x4edf6b0): TypeId = N12class_loader4impl10MetaObjectI3Cow4BaseEE Associated Library = libclass_loader_TestPlugins1.so Associated Loader 0 = 0x1ffeff8000--------------------------------------------------------------------------------Metaobject 2 (ptr = 0x4edec70): TypeId = N12class_loader4impl10MetaObjectI3Dog4BaseEE Associated Library = libclass_loader_TestPlugins1.so Associated Loader 0 = 0x1ffeff8000--------------------------------------------------------------------------------Metaobject 3 (ptr = 0x4edf380): TypeId = N12class_loader4impl10MetaObjectI4Duck4BaseEE Associated Library = libclass_loader_TestPlugins1.so Associated Loader 0 = 0x1ffeff8000--------------------------------------------------------------------------------Metaobject 4 (ptr = 0x4edf9e0): TypeId = N12class_loader4impl10MetaObjectI5Sheep4BaseEE Associated Library = libclass_loader_TestPlugins1.so Associated Loader 0 = 0x1ffeff8000--------------------------------------------------------------------------------********************************** END DEBUG *****************************************************************************************************************[ OK ] ClassLoaderUniquePtrTest.basicLoad (161 ms)[----------] 1 test from ClassLoaderUniquePtrTest (167 ms total)[----------] Global test environment tear-down[==========] 1 test from 1 test suite ran. (196 ms total)[ PASSED ] 1 test.==63164== ==63164== HEAP SUMMARY:==63164== in use at exit: 1,040 bytes in 20 blocks==63164== total heap usage: 502 allocs, 482 frees, 129,843 bytes allocated==63164== ==63164== 208 (16 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 20==63164== at 0x483DE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==63164== by 0x48A81A0: ???==63164== by 0x48A7667: ???==63164== by 0x48A7E35: ???==63164== by 0x48A7E7F: ???==63164== by 0x4011B99: call_init.part.0 (dl-init.c:72)==63164== by 0x4011CA0: call_init (dl-init.c:30)==63164== by 0x4011CA0: _dl_init (dl-init.c:119)==63164== by 0x4C8E984: _dl_catch_exception (dl-error-skeleton.c:182)==63164== by 0x40160CE: dl_open_worker (dl-open.c:758)==63164== by 0x4C8E927: _dl_catch_exception (dl-error-skeleton.c:208)==63164== by 0x4015609: _dl_open (dl-open.c:837)==63164== by 0x4EB034B: dlopen_doit (dlopen.c:66)==63164== ==63164== 208 (16 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 17 of 20==63164== at 0x483DE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==63164== by 0x48A8436: ???==63164== by 0x48A7815: ???==63164== by 0x48A7E41: ???==63164== by 0x48A7E7F: ???==63164== by 0x4011B99: call_init.part.0 (dl-init.c:72)==63164== by 0x4011CA0: call_init (dl-init.c:30)==63164== by 0x4011CA0: _dl_init (dl-init.c:119)==63164== by 0x4C8E984: _dl_catch_exception (dl-error-skeleton.c:182)==63164== by 0x40160CE: dl_open_worker (dl-open.c:758)==63164== by 0x4C8E927: _dl_catch_exception (dl-error-skeleton.c:208)==63164== by 0x4015609: _dl_open (dl-open.c:837)==63164== by 0x4EB034B: dlopen_doit (dlopen.c:66)==63164== ==63164== 208 (16 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 18 of 20==63164== at 0x483DE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==63164== by 0x48A86CC: ???==63164== by 0x48A79C3: ???==63164== by 0x48A7E4D: ???==63164== by 0x48A7E7F: ???==63164== by 0x4011B99: call_init.part.0 (dl-init.c:72)==63164== by 0x4011CA0: call_init (dl-init.c:30)==63164== by 0x4011CA0: _dl_init (dl-init.c:119)==63164== by 0x4C8E984: _dl_catch_exception (dl-error-skeleton.c:182)==63164== by 0x40160CE: dl_open_worker (dl-open.c:758)==63164== by 0x4C8E927: _dl_catch_exception (dl-error-skeleton.c:208)==63164== by 0x4015609: _dl_open (dl-open.c:837)==63164== by 0x4EB034B: dlopen_doit (dlopen.c:66)==63164== ==63164== 208 (16 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 20==63164== at 0x483DE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==63164== by 0x48A8962: ???==63164== by 0x48A7B71: ???==63164== by 0x48A7E59: ???==63164== by 0x48A7E7F: ???==63164== by 0x4011B99: call_init.part.0 (dl-init.c:72)==63164== by 0x4011CA0: call_init (dl-init.c:30)==63164== by 0x4011CA0: _dl_init (dl-init.c:119)==63164== by 0x4C8E984: _dl_catch_exception (dl-error-skeleton.c:182)==63164== by 0x40160CE: dl_open_worker (dl-open.c:758)==63164== by 0x4C8E927: _dl_catch_exception (dl-error-skeleton.c:208)==63164== by 0x4015609: _dl_open (dl-open.c:837)==63164== by 0x4EB034B: dlopen_doit (dlopen.c:66)==63164== ==63164== 208 (16 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 20 of 20==63164== at 0x483DE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==63164== by 0x48A8BF8: ???==63164== by 0x48A7D1F: ???==63164== by 0x48A7E65: ???==63164== by 0x48A7E7F: ???==63164== by 0x4011B99: call_init.part.0 (dl-init.c:72)==63164== by 0x4011CA0: call_init (dl-init.c:30)==63164== by 0x4011CA0: _dl_init (dl-init.c:119)==63164== by 0x4C8E984: _dl_catch_exception (dl-error-skeleton.c:182)==63164== by 0x40160CE: dl_open_worker (dl-open.c:758)==63164== by 0x4C8E927: _dl_catch_exception (dl-error-skeleton.c:208)==63164== by 0x4015609: _dl_open (dl-open.c:837)==63164== by 0x4EB034B: dlopen_doit (dlopen.c:66)==63164== ==63164== LEAK SUMMARY:==63164== definitely lost: 80 bytes in 5 blocks==63164== indirectly lost: 960 bytes in 15 blocks==63164== possibly lost: 0 bytes in 0 blocks==63164== still reachable: 0 bytes in 0 blocks==63164== suppressed: 0 bytes in 0 blocks==63164== ==63164== For lists of detected and suppressed errors, rerun with: -s==63164== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
Thanks for your reply. I have updated the description in #201 (comment). In order to not make the relative issue complicated, I used the existing test case to show the problem.
The reason will be displayed to describe this comment to others. Learn more.
Introducing unique_ptr can keep the meta object as long as proxy object is alive and guarantee to delete the object, this makes sense to address the issue.
Thanks for your information, but I think this PR is to address the memory leak about the meta-object is not destroyed during a process exit if using ClassLoader mentioned at #201 (comment). To make the sanitizer happy, I have created a new PR below for it.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
iuhilnehc-ynos
force-pushed
the
topic-meta-object-lifecycle
branch
from
This PR is to address the memory leak about the meta-object is not destroyed during a process exit if using
ClassLoader.memory leak log
Signed-off-by: Chen Lihui [email protected]