summaryrefslogtreecommitdiff
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
parenteb351a9e633e5893f0c3bb48808c3ed0280585b5 (diff)
downloadmusl-8fe5fa56eeade4fc19c5401861c179c2fdfeaf3d.tar.gz
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.
-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;