If a shared library (so) is loaded using dlopen and utilizes thread-local storage (TLS), the memory will not be freed upon thread exit, resulting in a memory leak.
This issue has been resolved in glibc-2.14. However, it remains unresolved in uClibc.
The following patch is based on the patch made in glibc and has been validated as effective on the x86-64 architecture.
diff --git a/libpthread/nptl/allocatestack.c b/libpthread/nptl/allocatestack.c index 7ef884543..941ef22f0 100644 --- a/libpthread/nptl/allocatestack.c +++ b/libpthread/nptl/allocatestack.c @@ -24,6 +24,7 @@ #include <unistd.h> #include <sys/mman.h> #include <sys/param.h> +#include <dl-tls.h> #include <tls.h> #include <lowlevellock.h> #include <link.h> @@ -241,6 +242,10 @@ get_cached_stack (size_t *sizep, void **memp)
/* Clear the DTV. */ dtv_t *dtv = GET_DTV (TLS_TPADJ (result)); + for (size_t cnt = 0; cnt < dtv[-1].counter; ++cnt) + if (! dtv[1 + cnt].pointer.is_static + && dtv[1 + cnt].pointer.val != TLS_DTV_UNALLOCATED) + free (dtv[1 + cnt].pointer.val); memset (dtv, '\0', (dtv[-1].counter + 1) * sizeof (dtv_t));
/* Re-initialize the TLS. */ diff --git a/libpthread/nptl/sysdeps/generic/dl-tls.c b/libpthread/nptl/sysdeps/generic/dl-tls.c index 7d25e4706..7b7991be8 100644 --- a/libpthread/nptl/sysdeps/generic/dl-tls.c +++ b/libpthread/nptl/sysdeps/generic/dl-tls.c @@ -45,8 +45,6 @@ to allow dynamic loading of modules defining IE-model TLS data. */ # define TLS_STATIC_SURPLUS 64 + DL_NNS * 100
-/* Value used for dtv entries for which the allocation is delayed. */ -# define TLS_DTV_UNALLOCATED ((void *) -1l)
#ifndef SHARED extern dtv_t static_dtv; diff --git a/libpthread/nptl/sysdeps/x86_64/dl-tls.h b/libpthread/nptl/sysdeps/x86_64/dl-tls.h index d6c338cda..5cac55f33 100644 --- a/libpthread/nptl/sysdeps/x86_64/dl-tls.h +++ b/libpthread/nptl/sysdeps/x86_64/dl-tls.h @@ -26,3 +26,6 @@ typedef struct
extern void *__tls_get_addr (tls_index *ti); + +/* Value used for dtv entries for which the allocation is delayed. */ +#define TLS_DTV_UNALLOCATED ((void *) -1l)
Ref:
https://sourceware.org/bugzilla/show_bug.cgi?id=12650
How to reproduce:
------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
Hi, Lumingxiang wrote,
If a shared library (so) is loaded using dlopen and utilizes thread-local storage (TLS), the memory will not be freed upon thread exit, resulting in a memory leak.
This issue has been resolved in glibc-2.14. However, it remains unresolved in uClibc.
The following patch is based on the patch made in glibc and has been validated as effective on the x86-64 architecture.
Is it possible to sent a git format-patch -s maybe as attachment? Your mail client mangled the patch.
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
diff --git a/libpthread/nptl/allocatestack.c b/libpthread/nptl/allocatestack.c
index 7ef884543..941ef22f0 100644
--- a/libpthread/nptl/allocatestack.c
+++ b/libpthread/nptl/allocatestack.c
@@ -24,6 +24,7 @@
#include <unistd.h>
#include <sys/mman.h>
#include <sys/param.h>
+#include <dl-tls.h>
#include <tls.h>
#include <lowlevellock.h>
#include <link.h>
@@ -241,6 +242,10 @@ get_cached_stack (size_t *sizep, void **memp)
/* Clear the DTV. */
dtv_t *dtv = GET_DTV (TLS_TPADJ (result));
for (size_t cnt = 0; cnt < dtv[-1].counter; ++cnt)
if (! dtv[1 + cnt].pointer.is_static
&& dtv[1 + cnt].pointer.val != TLS_DTV_UNALLOCATED)free (dtv[1 + cnt].pointer.val);memset (dtv, '\0', (dtv[-1].counter + 1) * sizeof (dtv_t));
/* Re-initialize the TLS. */
diff --git a/libpthread/nptl/sysdeps/generic/dl-tls.c b/libpthread/nptl/sysdeps /generic/dl-tls.c
index 7d25e4706..7b7991be8 100644
--- a/libpthread/nptl/sysdeps/generic/dl-tls.c
+++ b/libpthread/nptl/sysdeps/generic/dl-tls.c
@@ -45,8 +45,6 @@
to allow dynamic loading of modules defining IE-model TLS data. */# define TLS_STATIC_SURPLUS 64 + DL_NNS * 100
-/* Value used for dtv entries for which the allocation is delayed. */
-# define TLS_DTV_UNALLOCATED ((void *) -1l)
#ifndef SHARED
extern dtv_t static_dtv;
diff --git a/libpthread/nptl/sysdeps/x86_64/dl-tls.h b/libpthread/nptl/sysdeps/ x86_64/dl-tls.h
index d6c338cda..5cac55f33 100644
--- a/libpthread/nptl/sysdeps/x86_64/dl-tls.h
+++ b/libpthread/nptl/sysdeps/x86_64/dl-tls.h
@@ -26,3 +26,6 @@ typedef struct
extern void *__tls_get_addr (tls_index *ti);
+/* Value used for dtv entries for which the allocation is delayed. */
+#define TLS_DTV_UNALLOCATED ((void *) -1l)
Ref:
https://sourceware.org/bugzilla/show_bug.cgi?id=12650
How to reproduce:
Do you have example code to reproduce the issue?
best regards Waldemar
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
best regards && have a nice day! Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Friday, September 27, 2024 3:47 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
If a shared library (so) is loaded using dlopen and utilizes thread-local storage (TLS), the memory will not be freed upon thread exit, resulting in a memory leak.
This issue has been resolved in glibc-2.14. However, it remains unresolved in uClibc.
The following patch is based on the patch made in glibc and has been validated as effective on the x86-64 architecture.
Is it possible to sent a git format-patch -s maybe as attachment? Your mail client mangled the patch.
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
diff --git a/libpthread/nptl/allocatestack.c b/libpthread/nptl/allocatestack.c
index 7ef884543..941ef22f0 100644
--- a/libpthread/nptl/allocatestack.c
+++ b/libpthread/nptl/allocatestack.c
@@ -24,6 +24,7 @@
#include <unistd.h>
#include <sys/mman.h>
#include <sys/param.h>
+#include <dl-tls.h>
#include <tls.h>
#include <lowlevellock.h>
#include <link.h>
@@ -241,6 +242,10 @@ get_cached_stack (size_t *sizep, void **memp)
/* Clear the DTV. */
dtv_t *dtv = GET_DTV (TLS_TPADJ (result));
for (size_t cnt = 0; cnt < dtv[-1].counter; ++cnt)
if (! dtv[1 + cnt].pointer.is_static
&& dtv[1 + cnt].pointer.val != TLS_DTV_UNALLOCATED)free (dtv[1 + cnt].pointer.val);memset (dtv, '\0', (dtv[-1].counter + 1) * sizeof (dtv_t));
/* Re-initialize the TLS. */
diff --git a/libpthread/nptl/sysdeps/generic/dl-tls.c b/libpthread/nptl/sysdeps /generic/dl-tls.c
index 7d25e4706..7b7991be8 100644
--- a/libpthread/nptl/sysdeps/generic/dl-tls.c
+++ b/libpthread/nptl/sysdeps/generic/dl-tls.c
@@ -45,8 +45,6 @@
to allow dynamic loading of modules defining IE-model TLS data.*/
# define TLS_STATIC_SURPLUS 64 + DL_NNS * 100
-/* Value used for dtv entries for which the allocation is delayed. */
-# define TLS_DTV_UNALLOCATED ((void *) -1l)
#ifndef SHARED
extern dtv_t static_dtv;
diff --git a/libpthread/nptl/sysdeps/x86_64/dl-tls.h b/libpthread/nptl/sysdeps/ x86_64/dl-tls.h
index d6c338cda..5cac55f33 100644
--- a/libpthread/nptl/sysdeps/x86_64/dl-tls.h
+++ b/libpthread/nptl/sysdeps/x86_64/dl-tls.h
@@ -26,3 +26,6 @@ typedef struct
extern void *__tls_get_addr (tls_index *ti);
+/* Value used for dtv entries for which the allocation is delayed. +*/
+#define TLS_DTV_UNALLOCATED ((void *) -1l)
Ref:
https://sourceware.org/bugzilla/show_bug.cgi?id=12650
How to reproduce:
Do you have example code to reproduce the issue?
best regards Waldemar ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
Hi,
okay, thanks for the hint. I could reproduce the issue.
Unfortunately the patch is x86_64 specific. Would you be able to extend the patch for all architectures using NPTL?
best regards Waldemar
Lumingxiang wrote,
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi,
Certainly. Please refer to the attached file for the extended patch applicable to all architectures using NPTL. It has been verified on both x86 and mips64 architectures.
best regards Lumingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Tuesday, October 15, 2024 7:40 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: TLS memory-leak with dlopen
Hi,
okay, thanks for the hint. I could reproduce the issue.
Unfortunately the patch is x86_64 specific. Would you be able to extend the patch for all architectures using NPTL?
best regards Waldemar
Lumingxiang wrote,
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi,
sorry for your duplicate work. I didn't hear back from you and started to extend your patch which now is pushed.
Sorry.
But my patch is really similar to yours.
best regards Waldemar
Lumingxiang wrote,
Hi,
Certainly. Please refer to the attached file for the extended patch applicable to all architectures using NPTL. It has been verified on both x86 and mips64 architectures.
best regards Lumingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Tuesday, October 15, 2024 7:40 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: TLS memory-leak with dlopen
Hi,
okay, thanks for the hint. I could reproduce the issue.
Unfortunately the patch is x86_64 specific. Would you be able to extend the patch for all architectures using NPTL?
best regards Waldemar
Lumingxiang wrote,
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi, I apologize for not updating the patch and responding to the email promptly, as I've been quite busy lately. Could you please update the patch's author information to include my name and email addrerss? This is very important for both me and my company.
best regards Lu mingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Thursday, October 31, 2024 4:51 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: 回复: TLS memory-leak with dlopen
Hi,
sorry for your duplicate work. I didn't hear back from you and started to extend your patch which now is pushed.
Sorry.
But my patch is really similar to yours.
best regards Waldemar
Lumingxiang wrote,
Hi,
Certainly. Please refer to the attached file for the extended patch applicable to all architectures using NPTL. It has been verified on both x86 and mips64 architectures.
best regards Lumingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Tuesday, October 15, 2024 7:40 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: TLS memory-leak with dlopen
Hi,
okay, thanks for the hint. I could reproduce the issue.
Unfortunately the patch is x86_64 specific. Would you be able to extend the patch for all architectures using NPTL?
best regards Waldemar
Lumingxiang wrote,
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
--
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi,
which mailaddress you wanted? I used your first patch and just extended it.
best regards Waldemar
Lumingxiang wrote,
Hi, I apologize for not updating the patch and responding to the email promptly, as I've been quite busy lately. Could you please update the patch's author information to include my name and email addrerss? This is very important for both me and my company.
best regards Lu mingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Thursday, October 31, 2024 4:51 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: 回复: TLS memory-leak with dlopen
Hi,
sorry for your duplicate work. I didn't hear back from you and started to extend your patch which now is pushed.
Sorry.
But my patch is really similar to yours.
best regards Waldemar
Lumingxiang wrote,
Hi,
Certainly. Please refer to the attached file for the extended patch applicable to all architectures using NPTL. It has been verified on both x86 and mips64 architectures.
best regards Lumingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Tuesday, October 15, 2024 7:40 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: TLS memory-leak with dlopen
Hi,
okay, thanks for the hint. I could reproduce the issue.
Unfortunately the patch is x86_64 specific. Would you be able to extend the patch for all architectures using NPTL?
best regards Waldemar
Lumingxiang wrote,
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
--
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi,
I checked the submitted information, the email address is correct. Thank you very much！
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Thursday, October 31, 2024 7:41 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: 回复: 回复: TLS memory-leak with dlopen
Hi,
which mailaddress you wanted? I used your first patch and just extended it.
best regards Waldemar
Lumingxiang wrote,
Hi, I apologize for not updating the patch and responding to the email promptly, as I've been quite busy lately. Could you please update the patch's author information to include my name and email addrerss? This is very important for both me and my company.
best regards Lu mingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Thursday, October 31, 2024 4:51 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: 回复: TLS memory-leak with dlopen
Hi,
sorry for your duplicate work. I didn't hear back from you and started to extend your patch which now is pushed.
Sorry.
But my patch is really similar to yours.
best regards Waldemar
Lumingxiang wrote,
Hi,
Certainly. Please refer to the attached file for the extended patch applicable to all architectures using NPTL. It has been verified on both x86 and mips64 architectures.
best regards Lumingxiang
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Tuesday, October 15, 2024 7:40 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: 回复: TLS memory-leak with dlopen
Hi,
okay, thanks for the hint. I could reproduce the issue.
Unfortunately the patch is x86_64 specific. Would you be able to extend the patch for all architectures using NPTL?
best regards Waldemar
Lumingxiang wrote,
Hi, Waldemar Brodkorb, I apologize for forgetting to mention earlier that Valgrind was initially unable to detect the memory leak. At first, we also used Valgrind for analysis, but it didn’t catch the memory leak. However, by monitoring memory usage with the command cat /proc/[pid]/status | grep VmRSS, we observed a continuous increase in the size of the target process. After applying the patch, this memory leakage issue was resolved. Could you please try using it?
best regards Mingxiang Lu
-----邮件原件----- 发件人: Waldemar Brodkorb wbx@openadk.org 发送时间: Monday, September 30, 2024 11:15 PM 收件人: lumingxiang (操作系统开发部/NingOS, RD) lu.mingxiang@h3c.com 抄送: Waldemar Brodkorb wbx@openadk.org; devel@uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) zhang.chunA@h3c.com 主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi, Lumingxiang wrote,
Hi, Waldemar Brodkorb,
Is it possible to sent a git format-patch -s maybe as attachment?
Certainly, please find the attachment.
Okay, thanks.
Do you have example code to reproduce the issue?
Yes, please see the attached example code. The two source files are compiled into a shared object and an application respectively. Instructions for compiling them can be found in the first lines of the files.
I tried attached code with valgrind in qemu-system-x86_64 with a uClibc-ng master system, but valgrind did not found any memleak. Furthermore I tried the code in the original bugreport, but here also no memleak is found. Any idea? Can you post the output of valgrind? Can you see the memleak?
Furthermore can you subscribe to the mailinglist, I had to manually pass your mail.
Of course, I have already subscribed to the mailing list.
Thanks.
best regards Waldemar
--
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
-
Lumingxiang -
Waldemar Brodkorb