This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: A patch for linuxthreads
- To: hjl@lucon.org, libc-hacker@cygnus.com
- Subject: Re: A patch for linuxthreads
- From: mrs@wrs.com (Mike Stump)
- Date: Wed, 17 Mar 1999 13:44:31 -0800
> From: hjl@lucon.org (H.J. Lu)
> To: libc-hacker@cygnus.com (GNU C Library)
> Date: Tue, 16 Mar 1999 20:28:23 -0800 (PST)
> The problem is we should not access those key data stuctures after
> a thread is terminared since they have been freed.
> The patch for Versions fixes another bug.
> Index: specific.c
> ===================================================================
> RCS file: /work/cvs/gnu/glibc/linuxthreads/specific.c,v
> retrieving revision 1.1.1.5
> diff -u -p -r1.1.1.5 specific.c
> --- specific.c 1998/12/01 16:22:30 1.1.1.5
> +++ specific.c 1999/03/17 03:30:10
> @@ -80,7 +80,7 @@ int pthread_key_delete(pthread_key_t key
> idx2nd = key % PTHREAD_KEY_2NDLEVEL_SIZE;
> th = self;
> do {
> - if (th->p_specific[idx1st] != NULL)
> + if (!th->p_terminated && th->p_specific[idx1st] != NULL)
> th->p_specific[idx1st][idx2nd] = NULL;
> th = th->p_nextlive;
> } while (th != self);
Forgive my possible ignorance, but if on an future SMP system, you can
have two threads running on different CPUs at the same time in a
shared memory system, and there is no `other' locking, the above seems
like it needs a lock around it.