Patch for glibc-linuxthreads-2.1.1

[Kaz Kylheku <kaz@ashi.footprints.net>]

If the thread manager is unable to clone() a process, it must undo some
resource allocations that it performed in preparation of the new thread:
namely, it must unmap the initial stack (if one was created) and stack guard
page.  HOwever, this is messed up! The guard page must be unmapped first, then
the stack. Because the top of the stack holds the thread structure which is
needed to retrieve the pointer to the guard page. Here is the patch.

This bug will cause the thread manager to segfault and turn into a zombie,
which results in massive deadlock in a threaded application. Such 
a failure scenario was detected by Igor Khasilev, who posted his
observations in to comp.programming.threads.

--- manager.c.orig      Tue Jul  6 14:09:24 1999
+++ manager.c   Tue Jul  6 14:11:13 1999
@@ -379,10 +379,10 @@ static int pthread_handle_create(pthread
     /* Free the stack if we allocated it */
     if (attr == NULL || !attr->__stackaddr_set)
       {
-       munmap((caddr_t)((char *)(new_thread+1) - INITIAL_STACK_SIZE),
-              INITIAL_STACK_SIZE);
        if (new_thread->p_guardsize != 0)
          munmap(new_thread->p_guardaddr, new_thread->p_guardsize);
+       munmap((caddr_t)((char *)(new_thread+1) - INITIAL_STACK_SIZE),
+              INITIAL_STACK_SIZE);
       }
     __pthread_handles[sseg].h_descr = NULL;
     __pthread_handles[sseg].h_bottom = NULL;