If I override the libc free() function, and change that function to clobber some
bytes of the data, and then call pthread_getspecific from that function,
pthread_getspecific can return bad data. This is because __nptl_deallocate_tsd
frees data before clearing the pointer to that data. This happens around line 185:
/* The first block is allocated as part of the thread
THREAD_SETMEM_NC (self, specific, cnt, NULL);
The order of those lines should be reversed.
I first noticed this bug in linuxthreads, and then discovered that NPTL had the
same bug. I will file a separate bug against linuxthreads.
I will attach a test case which shows the problem on i686-pc-linux-gnu using
Fedora Core 4 with glibc-2.3.6-3.
Created attachment 1356 [details]
This test case crashes for me on i686-pc-linux-gnu running Fedora Core 4 with
glibc-2.3.6-3. In the __libc_free routine, pthread_getspecific returns
That's plainly invalid code. You cannot use the TSD anymore when it gets destroyed.
That was, of course, just an example which tests for whether the problem exists.
The issue is overriding malloc(), free() and friends, where they use pthread
specific keys, and where free clobbers the block data for debugging purposes.
Since the pthread code itself calls free, it is impossible for free to know
whether or not the pthread specific key has been destroyed. The only way is for
free to check whether pthread_get_specific returns NULL, but that doesn't work
if it clobbers the data for debugging purposes.
I can't say that I'm surprised that you plan to ignore this bug report.
However, I hope the report will give a hint to distros to swap the order of
those two lines.
THere will be no change. You are introducing wrong behavior. If this wrong
code should be worked around with a patch like this then somebody would complain
that TSD data is left behind and demand this is handled. It's a rats nest. If
your program is invalid it must crash ASAP.
Thank you for your thoughtful and detailed analysis showing why this useful
approach to memory allocation and debugging is invalid. Thank for your decision
to not swap two lines of code, as it is clearly a slippery slope to destroying
libc. As always, I stand astounded by your technical decisions and your ability