thread specific storage bug?

[Matthew Newhook]

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