about summary refs log tree commit diff
path: root/src/thread
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2011-09-11 12:35:41 -0400
committerRich Felker <dalias@aerifal.cx>2011-09-11 12:35:41 -0400
commit8fe5fa56eeade4fc19c5401861c179c2fdfeaf3d (patch)
tree2894fdb08fec69e2a1e51e36081f00ac69f2f127 /src/thread
parenteb351a9e633e5893f0c3bb48808c3ed0280585b5 (diff)
downloadmusl-8fe5fa56eeade4fc19c5401861c179c2fdfeaf3d.tar.gz
musl-8fe5fa56eeade4fc19c5401861c179c2fdfeaf3d.tar.xz
musl-8fe5fa56eeade4fc19c5401861c179c2fdfeaf3d.zip
fix serious bug in pthread_join
on spurious wakeups/returns from __timedwait, pthread_join would
"succeed" and unmap the thread's stack while it was still running. at
best this would lead to SIGSEGV when the thread resumed execution, but
in the worst case, the thread would later resume executing on top of
another new thread's stack mapped at the same address.

spent about 4 hours tracking this bug down, chasing rare
difficult-to-reproduce stack corruption in a stress test program.
still no idea *what* caused the spurious wakeups; i suspect it's a
kernel bug.
Diffstat (limited to 'src/thread')
-rw-r--r--src/thread/pthread_join.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/src/thread/pthread_join.c b/src/thread/pthread_join.c
index 1b0c4f35..86191f25 100644
--- a/src/thread/pthread_join.c
+++ b/src/thread/pthread_join.c
@@ -6,8 +6,8 @@ static void dummy(void *p)
 
 int pthread_join(pthread_t t, void **res)
 {
-	int tmp = t->tid;
-	if (tmp) __timedwait(&t->tid, tmp, 0, 0, dummy, 0, 0);
+	int tmp;
+	while ((tmp = t->tid)) __timedwait(&t->tid, tmp, 0, 0, dummy, 0, 0);
 	if (res) *res = t->result;
 	if (t->map_base) munmap(t->map_base, t->map_size);
 	return 0;