[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
thread specific storage bug?
From: |
Matthew Newhook |
Subject: |
thread specific storage bug? |
Date: |
Mon, 16 Oct 2000 12:09:02 -0230 |
Hi,
We're noting a problem with glibc 2.1.3-15. The problem is that we
delete some thread specific storage before all threads have gone away
(they are actually in the _process_ of disappearing). This causes
memory corruptions in our application.
From looking at linuxthreads/specific.c I can see why:
pthread_key_delete runs through the threads setting the specific
storage data to NULL
do {
/* If the thread already is terminated don't modify the memory. */
if (!th->p_terminated && th->p_specific[idx1st] != NULL)
th->p_specific[idx1st][idx2nd] = NULL;
^^^^ - here
th = th->p_nextlive;
} while (th != self);
__pthread_destroy_specifics has the following loop:
for (i = 0; i < PTHREAD_KEY_1STLEVEL_SIZE; i++) {
if (THREAD_GETMEM_NC(self, p_specific[i]) != NULL)
free(THREAD_GETMEM_NC(self, p_specific[i]));
^^^^^
}
At the point that __pthread_destroy_specifics runs p_terminated is 0.
So what can occur is that pthread_key_delete can set free'd memory
to NULL.
Regards, Matthew
--
Matthew Newhook E-Mail: mailto:address@hidden
Software Designer WWW: http://www.ooc.com
Object Oriented Concepts, Inc. Phone: (709) 738-3725
- thread specific storage bug?,
Matthew Newhook <=