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.

Sign up for GitHub

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

Jump to bottom

Memory leak #15

Closed
lukasmacko opened this issue Feb 5, 2016 · 6 comments
Closed

Memory leak #15

lukasmacko opened this issue Feb 5, 2016 · 6 comments

Comments

@lukasmacko
Copy link
Contributor 

 #include <stdio.h>
 #include <stdlib.h>
 #include <libyang/libyang.h>

 int main(int argc, char **argv)
 {
     struct ly_ctx *ctx = ly_ctx_new(".");
     ly_ctx_destroy(ctx, NULL);
 }

==23495== HEAP SUMMARY:
==23495== in use at exit: 4 bytes in 1 blocks
==23495== total heap usage: 1,536 allocs, 1,535 frees, 149,576 bytes allocated
==23495==
==23495== 4 bytes in 1 blocks are still reachable in loss record 1 of 1
==23495== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23495== by 0x4E44502: ly_errno_location (common.c:58)
==23495== by 0x4E5F970: lyxml_parse_mem (xml.c:1131)
==23495== by 0x4E85CE4: yin_read_module (parser_yin.c:5300)
==23495== by 0x4E901BC: lys_parse_mem (tree_schema.c:1057)
==23495== by 0x4E4607E: ly_ctx_new (context.c:87)
==23495== by 0x400705: main (main.c:7)
==23495==
==23495== LEAK SUMMARY:
==23495== definitely lost: 0 bytes in 0 blocks
==23495== indirectly lost: 0 bytes in 0 blocks
==23495== possibly lost: 0 bytes in 0 blocks
==23495== still reachable: 4 bytes in 1 blocks
==23495== suppressed: 0 bytes in 0 blocks
==23495==
@rkrejci
Copy link
Collaborator

rkrejci commented Feb 5, 2016

We know about this, but it seems that the destructor registered with pthread_key_create() is
a) not executed on the main thread or
b) is (in case of the main thread) executed after valgrind gets the data for this summary.

The issue is always on the main thread, thread-specific data in other threads are freed correctly.

@lukasmacko
Copy link
Contributor Author

Ok, I'll workaround it with valgrind suppression file

{ 
   libyang_pthread_key_create
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:calloc
   fun:ly_errno_location
   fun:lyxml_parse_mem
   fun:yin_read_module
   fun:lys_parse_mem
   fun:ly_ctx_new
}

@rkrejci rkrejci closed this as completed in 4f9fd68 Feb 5, 2016
rkrejci added a commit that referenced this issue Feb 5, 2016
@rkrejci
HACK "memory leak" of ly_errno in main thread
fd8c59b 
It wasn't actually a real memory leak, there was just still reachable
dynamically allocated memory on process exit, because the destructor
registered by pthread_key_create() in the main thread isn't executed
on process termination but only on thread termination (i.e. on
pthread_exit()).

So, on Linux, we are going to use static memory for the main thread's
ly_errno.

Fixes #15
@rkrejci
Copy link
Collaborator

rkrejci commented Feb 5, 2016

The workaround with valgrind suppression file shouldn't be no more necessary on Linux. I have added Linux specific (non-portable) code to use static memory in case of the main thread. It shouldn't change functionality in any way, it is supposed just to suppress the valgrind message.

@lukasmacko
Copy link
Contributor Author

The leak has returned in 2f83dc8 It appears if it the variable is initialized in a thread. Previous commit 843f419 works ok.

24: ==23881== 4 bytes in 1 blocks are definitely lost in loss record 1 of 5
24: ==23881== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
24: ==23881== by 0x587EDAF: ly_errno_location (common.c:90)
24: ==23881== by 0x588F444: lyxml_parse_mem (xml.c:1131)
24: ==23881== by 0x58B3C2F: lyd_parse_ (tree_data.c:67)
24: ==23881== by 0x58B3E0D: lyd_parse_data_ (tree_data.c:106)
24: ==23881== by 0x58B4088: lyd_parse_fd (tree_data.c:147)
24: ==23881== by 0x44E70A: dm_load_data_tree (data_manager.c:314)
24: ==23881== by 0x450152: dm_copy_data_info (data_manager.c:466)
24: ==23881== by 0x45274F: dm_get_data_info (data_manager.c:689)
24: ==23881== by 0x452FA0: dm_get_datatree (data_manager.c:728)
24: ==23881== by 0x445AC0: rp_dt_get_value_wrapper (rp_dt_get.c:362)
24: ==23881== by 0x43573C: rp_get_item_req_process (request_processor.c:153)

rkrejci added a commit that referenced this issue Feb 8, 2016
@rkrejci
BUGFIX memory leak
1d7f8d2 
Since pthread_once() is called only once in a process, also the destructor
in pthread_key_create() is the same for all threads. But we use dynamic
memory for threads and static memory for the main thread. Therefore, we
have to check in destructor (and we cannot use standard free()) for freeing
static memory if someone will use pthread_exit() in main().

Fixes #15
rkrejci added a commit that referenced this issue Feb 8, 2016
@rkrejci
BUGFIX memory leak
38efcf2 
Since pthread_once() is called only once in a process, also the destructor
in pthread_key_create() is the same for all threads. But we use dynamic
memory for threads and static memory for the main thread. Therefore, we
have to check in destructor (and we cannot use standard free()) for freeing
static memory if someone will use pthread_exit() in main().

Fixes #15
@rkrejci
Copy link
Collaborator

rkrejci commented Feb 8, 2016

Thanks Lukas, should work now.

@lukasmacko
Copy link
Contributor Author

Yes, it does. Thanks

PavolVican pushed a commit that referenced this issue Feb 9, 2016
@rkrejci @PavolVican
HACK "memory leak" of ly_errno in main thread
341bddb 
It wasn't actually a real memory leak, there was just still reachable
dynamically allocated memory on process exit, because the destructor
registered by pthread_key_create() in the main thread isn't executed
on process termination but only on thread termination (i.e. on
pthread_exit()).

So, on Linux, we are going to use static memory for the main thread's
ly_errno.

Fixes #15
PavolVican pushed a commit that referenced this issue Feb 9, 2016
@rkrejci @PavolVican
BUGFIX memory leak
e69a7d7 
Since pthread_once() is called only once in a process, also the destructor
in pthread_key_create() is the same for all threads. But we use dynamic
memory for threads and static memory for the main thread. Therefore, we
have to check in destructor (and we cannot use standard free()) for freeing
static memory if someone will use pthread_exit() in main().

Fixes #15
alangefe pushed a commit to ADTRAN/libyang that referenced this issue Aug 7, 2018
@rkrejci
server edit-config BUGFIX leaf-list need a key
c8b7f44 
When targetting leaflist, its value must be specified as key (predicate)
in the XPath expression.

Fixes CESNET#15
alangefe pushed a commit to ADTRAN/libyang that referenced this issue Aug 7, 2018
@rkrejci
server edit-config BUGFIX leaf-list need a key
48570aa 
When targetting leaflist, its value must be specified as key (predicate)
in the XPath expression.

Fixes CESNET#15
@woytowg woytowg mentioned this issue Apr 23, 2019
Closed
@RavikumarTulugu RavikumarTulugu mentioned this issue May 28, 2020
Closed
@robbynet robbynet mentioned this issue Jun 20, 2020
Closed
@antony-rheneus antony-rheneus mentioned this issue Nov 18, 2020
Closed
@yhyy791228 yhyy791228 mentioned this issue Nov 19, 2020
Closed
@rabhat31 rabhat31 mentioned this issue May 17, 2021
Closed
@vpestret vpestret mentioned this issue May 28, 2021
Closed
@AeroFlorian AeroFlorian mentioned this issue May 5, 2022
Closed
@MoshikaKarthesan MoshikaKarthesan mentioned this issue Aug 11, 2023
Closed
@rekib66 rekib66 mentioned this issue May 21, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rkrejci @lukasmacko