26 Sep
2024
26 Sep
'24
7:54 a.m.
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!
27 Sep
27 Sep
7:47 a.m.
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
29 Sep
29 Sep
12:52 p.m.
New subject: 回复: TLS memory-leak with dlopen
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(a)openadk.org>
发送时间: Friday, September 27, 2024 3:47 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: devel(a)uclibc-ng.org; zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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!
30 Sep
30 Sep
3:14 p.m.
New subject: 回复: TLS memory-leak with dlopen
Hi,
Lumingxiang wrote,
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?
Thanks.
best regards
Waldemar
Hi,
Waldemar Brodkorb,
Okay, thanks.
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.
14 Oct
14 Oct
11:57 a.m.
New subject: 回复: 回复: TLS memory-leak with dlopen
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(a)openadk.org>
发送时间: Monday, September 30, 2024 11:15 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)h3c.com>
主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi,
Lumingxiang wrote,
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?
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,
Waldemar Brodkorb,
Okay, thanks.
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.
15 Oct
15 Oct
11:40 a.m.
New subject: 回复: 回复: 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(a)openadk.org>
发送时间: Monday, September 30, 2024 11:15 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)h3c.com>
主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi,
Lumingxiang wrote,
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?
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(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
Hi,
Waldemar Brodkorb,
Okay, thanks.
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.
31 Oct
31 Oct
8:30 a.m.
New subject: 回复: 回复: 回复: TLS memory-leak with dlopen
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(a)openadk.org>
发送时间: Tuesday, October 15, 2024 7:40 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
发送时间: Monday, September 30, 2024 11:15 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)h3c.com>
主题: Re: [uclibc-ng-devel] 回复: TLS memory-leak with dlopen
Hi,
Lumingxiang wrote,
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?
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(a)uclibc-ng.org To unsubscribe send an email
to devel-leave(a)uclibc-ng.org
Hi,
Waldemar Brodkorb,
Okay, thanks.
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.
8:51 a.m.
New subject: 回复: 回复: 回复: 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(a)openadk.org>
发送时间: Tuesday, October 15, 2024 7:40 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
> 发送时间: Monday, September 30, 2024 11:15 PM
> 收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
> 抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
> zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)uclibc-ng.org To unsubscribe send an email
> to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
9:22 a.m.
New subject: 回复: 回复: 回复: 回复: TLS memory-leak with dlopen
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(a)openadk.org>
发送时间: Thursday, October 31, 2024 4:51 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
发送时间: Tuesday, October 15, 2024 7:40 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
> 发送时间: Monday, September 30, 2024 11:15 PM
> 收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
> 抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
> zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)uclibc-ng.org To unsubscribe send an
> email to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org To unsubscribe send an email
to devel-leave(a)uclibc-ng.org
11:41 a.m.
New subject: 回复: 回复: 回复: 回复: 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(a)openadk.org>
发送时间: Thursday, October 31, 2024 4:51 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
发送时间: Tuesday, October 15, 2024 7:40 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
> 发送时间: Monday, September 30, 2024 11:15 PM
> 收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
> 抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
> zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)uclibc-ng.org To unsubscribe send an
> email to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org To unsubscribe send an email
to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
1:21 p.m.
New subject: 回复: 回复: 回复: 回复: 回复: TLS memory-leak with dlopen
Hi,
I checked the submitted information, the email address is correct.
Thank you very much！
best regards
Mingxiang Lu
-----邮件原件-----
发件人: Waldemar Brodkorb <wbx(a)openadk.org>
发送时间: Thursday, October 31, 2024 7:41 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org; zhangchun
(操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
发送时间: Thursday, October 31, 2024 4:51 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
发送时间: Tuesday, October 15, 2024 7:40 PM
收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)openadk.org>
> 发送时间: Monday, September 30, 2024 11:15 PM
> 收件人: lumingxiang (操作系统开发部/NingOS, RD) <lu.mingxiang(a)h3c.com>
> 抄送: Waldemar Brodkorb <wbx(a)openadk.org>rg>; devel(a)uclibc-ng.org;
> zhangchun (操作系统开发部/NingOS, RD) <zhang.chunA(a)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(a)uclibc-ng.org To unsubscribe send an
> email to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org To unsubscribe send an
email to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org To unsubscribe send an email
to devel-leave(a)uclibc-ng.org
133
days inactive
168
days old
10 comments
2 participants
participants (2)
-
Lumingxiang -
Waldemar Brodkorb