--- Comment #7 from fgiasson1 at yahoo dot ca 2009-03-05 20:02 ---
OK but shouldn't libstdc++ handle static __thread variables cleaning for
exceptions? libc doesn't know about exceptions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39366
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-03-05 19:43 ---
(In reply to comment #5)
> Yes but this static __thread variable must be freed somehow when the thread
> exits.
They are freed when the thread is destroyed or should be. The compiler does
not know much about thread
--- Comment #5 from fgiasson1 at yahoo dot ca 2009-03-05 19:37 ---
Yes but this static __thread variable must be freed somehow when the thread
exits.
static __thread variables instantiated elsewhere but in exceptions do not cause
leaks. However, when allocated in the exception handling
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-05 18:08 ---
Lets look at the source:
static __thread abi::__cxa_eh_globals global;
return &global;
So I still think this is a bug in glibc. Look how we just return the address
to TLS variable.
--
http://gcc.gnu.o
--- Comment #3 from fgiasson1 at yahoo dot ca 2009-03-05 18:04 ---
Andrew,
Thanks for your answer.
I did the test you suggested and there is no leak associated to it, so I
believe this pretty much sorts out the possibility that a bug in libc leads to
the leak. Moreover, as I said in th
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-04 20:14 ---
It looks like glibc is not clearing up dlopened TLS allocated memory.
A simple testcase for glibc would be put into a shared library something like:
__thread int a;
int f(void)
{
return a;
}
--- CUT ---
And then
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-04 20:06 ---
This sounds like a bug in glibc or valgrind.
==16376== 8 bytes in 1 blocks are definitely lost in loss record 1 of 12
==16376==at 0x402517F: memalign (vg_replace_malloc.c:460)
==16376==by 0x401055F: ___tls_
