bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thread specific storage bug?


From: Matthew Newhook
Subject: Re: thread specific storage bug?
Date: Mon, 16 Oct 2000 14:21:39 -0230

Hi,

  It's pretty difficult to make a test case for this without altering
  glibc because I have to arrange for the CPU scheduling to be
  such that the application is in __pthread_destroy_specifics _and_
  pthread_key_delete at the same time...

  However, a review of the source should convince you that a problem
  does indeed exist...

  Consider two threads:

  T1: __pthread_destroy_specifics:

  This thread is running this loop. It has freed the item at
  p_specific[0].

  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]));
  }

  T2: pthread_key_delete:

  do {
    /* If the thread already is terminated don't modify the memory.  */
    if (!th->p_terminated && th->p_specific[idx1st] != NULL) <- HERE
      th->p_specific[idx1st][idx2nd] = NULL;
    th = th->p_nextlive;
  } while (th != self);

  This thread checks the conditional. p_terminated is 0 since this is
  set after __pthread_destroy_specifics has run. p_specific[0] isn't NULL
  (in this case) -- so this thread can write to deallocated memory.

  Regards, Matthew

On Mon, Oct 16, 2000 at 05:41:16PM +0200, Wolfram Gloger wrote:
> Hello,
> 
> >   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.
> 
> I can't see how you can arrange in your program that
> pthread_key_delete() is executed _after_ __pthread_destroy_specifics()
> has free'd the 1st level keys.
> 
> pthread_key_delete() is callable from thread destructor functions,
> sure, but __pthread_destroy_specifics() only frees the 1st level keys
> _after_ all destructor functions (and hence all possible
> pthread_key_delete()'s) have been called.
> 
> Can you either explain your problem in more detail or provide a short
> test case?
> 
> Regards,
> Wolfram.

-- 
Matthew Newhook                         E-Mail: mailto:address@hidden
Software Designer                       WWW:    http://www.ooc.com
Object Oriented Concepts, Inc.          Phone:  (709) 738-3725



reply via email to

[Prev in Thread] Current Thread [Next in Thread]