| Message ID | 43a99bde957d42369c331f1bbff80c52@h3c.com |
|---|---|
| State | New |
| Headers | show |
| Series | [uclibc-ng-devel] TLS memory-leak with dlopen | expand |
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! // gcc -g -O0 -o main ./tls_main.c -L. -lthreadfunc -ldl -lpthread #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <dlfcn.h> #include <stdint.h> #include <unistd.h> typedef void* (*thread_func_t)(void*); int main() { pthread_t thread; void* handle; thread_func_t thread_func; handle = dlopen("./libthreadfunc.so", RTLD_LAZY); if (!handle) { fprintf(stderr, "Failed to load libthreadfunc.so: %s\n", dlerror()); exit(EXIT_FAILURE); } dlerror(); thread_func = (thread_func_t)dlsym(handle, "thread_func"); const char* dlsym_error = dlerror(); if (dlsym_error) { fprintf(stderr, "Failed to find symbol thread_func: %s\n", dlsym_error); dlclose(handle); exit(EXIT_FAILURE); } while (1) { if (pthread_create(&thread, NULL, thread_func, NULL)!= 0) { perror("Failed to create thread"); dlclose(handle); exit(EXIT_FAILURE); } sleep(1); } dlclose(handle); return 0; } // gcc -g -O0 -fPIC -shared -o libthreadfunc.so tls_func.c -lpthread #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <unistd.h> #include <string.h> #define TLS_SIZE 8192UL static __thread char g_sArray[TLS_SIZE ] ; void* thread_func(void* arg) { pthread_t tid = pthread_self(); memset(g_sArray, 0, sizeof(g_sArray)); snprintf(g_sArray, sizeof(g_sArray), "Thread ID: %lu", (unsigned long)tid); printf("g_sArray:%s\n", g_sArray); pthread_detach(pthread_self()); return NULL; }
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
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)