Re: libc 2.2.4 is broken

[Mark Kettenis]

   From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
   Date: Mon, 20 Aug 2001 19:46:30 +0200

   Hi,

   libc 2.2.4 is broken.  I verified that the ABI-tag note section is fine,
   and the binaries work with the lastes binary package I produced, so
   it is a new bug.  Below is a backtrace.

Unfortunately yes.  Attached is a patch I sent to Roland, but I didn't
hear from him, so it isn't checked in yet.  Hmm, roland is still
aliased to roland@frob.com, does that still work Roland?

Mark

------- Start of forwarded message -------
Date: 18 Aug 2001 14:39:04 +0200
To: roland@frob.com
Subject: Cthreads-using programs crash with current glibc

Ulrich's changes to malloc/malloc.c exposed a problem with the Hurd
libc startup code.  The cthreads initialization code uses malloc.  The
malloc initialization code in turn searches for some environment
variables.  But when we run the cthreads initialization code, we
haven't initialized __environ yet.  Before Ulrich's change this didn't
cause a fatal problem since getenv checks whether __environ is NULL,
but now we crash when scanning the environment in next_env_entry.  Of
course this all means that we've been ignoring the various malloc
(debugging) options for cthreads-using programs until now.

Hmm, this also means that the 2.2.4 release is unusable for the Hurd
:-(.

The attached patch fixes things.  OK, to check this in?

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

        * sysdeps/mach/hurd/i386/init-first.c (init): Initialize __environ
        before calling the cthreads initialization code.

Index: sysdeps/mach/hurd/i386/init-first.c
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/mach/hurd/i386/init-first.c,v
retrieving revision 1.26
diff -u -p -r1.26 init-first.c
- --- sysdeps/mach/hurd/i386/init-first.c 2001/08/11 19:41:25 1.26
+++ sysdeps/mach/hurd/i386/init-first.c 2001/08/18 12:19:26
@@ -132,11 +132,19 @@ init (int *data)
   struct hurd_startup_data *d;
   unsigned long int threadvars[_HURD_THREADVAR_MAX];
 
- -  /* Provide temporary storage for thread-specific variables on the startup
- -     stack so the cthreads initialization code can use them for malloc et al,
- -  or so we can use malloc below for the real threadvars array.  */
+  /* Provide temporary storage for thread-specific variables on the
+     startup stack so the cthreads initialization code can use them
+     for malloc et al, or so we can use malloc below for the real
+     threadvars array.  */
   memset (threadvars, 0, sizeof threadvars);
   __hurd_threadvar_stack_offset = (unsigned long int) threadvars;
+
+  /* Since the cthreads initialization code uses malloc, and the
+     malloc initialization code needs to get at the environment, make
+     sure we can find it.  We'll need to do this again later on since
+     switching stacks changes the location where the environment is
+     stored.  */
+  __environ = envp;
 
   while (*envp)
     ++envp;
------- End of forwarded message -------