[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thread specific storage bug?
From: |
Wolfram Gloger |
Subject: |
Re: thread specific storage bug? |
Date: |
Mon, 16 Oct 2000 19:44:08 +0200 (MDT) |
Thanks for your reply, it was much clearer for me!
> I'm not calling pthread_key_delete from a thread destructor function.
OK.
> It's being called in main() after my threads have (mostly) gone away. The
> problem occurs when __pthread_destroy_specifics() and pthread_key_delete
> runs concurrently.
Right, I see what you mean now - no need for a test case. Below is an
untested patch against current glibc-2.2 that should fix this. I will
test and report results later.
Regards,
Wolfram.
Index: libc/linuxthreads/specific.c
===================================================================
RCS file: /cvs/glibc/libc/linuxthreads/specific.c,v
retrieving revision 1.10
diff -u -r1.10 specific.c
--- specific.c 1999/09/25 17:51:56 1.10
+++ specific.c 2000/10/16 17:39:46
@@ -78,8 +78,13 @@
th = self;
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;
+ if (!th->p_terminated) {
+ /* pthread_exit() may try to free th->p_specific[idx1st] concurrently. */
+ __pthread_lock(THREAD_GETMEM(th, p_lock), self);
+ if (th->p_specific[idx1st] != NULL)
+ th->p_specific[idx1st][idx2nd] = NULL;
+ __pthread_unlock(THREAD_GETMEM(th, p_lock));
+ }
th = th->p_nextlive;
} while (th != self);
pthread_mutex_unlock(&pthread_keys_mutex);
@@ -151,10 +156,14 @@
}
}
}
+ __pthread_lock(THREAD_GETMEM(self, p_lock), self);
for (i = 0; i < PTHREAD_KEY_1STLEVEL_SIZE; i++) {
- if (THREAD_GETMEM_NC(self, p_specific[i]) != NULL)
+ if (THREAD_GETMEM_NC(self, p_specific[i]) != NULL) {
free(THREAD_GETMEM_NC(self, p_specific[i]));
+ THREAD_SETMEM_NC(self, p_specific[i], NULL);
+ }
}
+ __pthread_unlock(THREAD_GETMEM(self, p_lock));
}
/* Thread-specific data for libc. */