From xemacs-m  Mon Jan 27 01:37:21 1997
Received: from dres.elam.org (dres@cola187.scsn.net [206.25.247.187])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id BAA14704 for <xemacs-beta@xemacs.org>; Mon, 27 Jan 1997 01:37:19 -0600 (CST)
Received: (from dres@localhost)
          by dres.elam.org (8.8.4/8.8.4)
	  id CAA22000; Mon, 27 Jan 1997 02:33:41 -0500
To: David Moore <dmoore@UCSD.EDU>
Cc: xemacs-beta@xemacs.org
Subject: Re: fix for temacs crash on linux libc 5.4.20
References: <hhraj7yalf.fsf@dres.elam.org> <m23evneixz.fsf@altair.xemacs.org>
	<rvwwsz7hfg.fsf@sdnp5.ucsd.edu>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII
From: James LewisMoss <dres@scsn.net>
Date: 27 Jan 1997 02:33:41 -0500
In-Reply-To: David Moore's message of 26 Jan 1997 22:36:51 -0800
Message-ID: <hhn2tvy3l6.fsf@dres.elam.org>
Lines: 44
X-Mailer: Gnus v5.2.40/XEmacs 20.0

>>>>> "David" == David Moore <dmoore@UCSD.EDU> writes:

 David> Steven L Baur <steve@miranova.com> writes:
 >> James LewisMoss writes:
 >> 
 >> > Seems mallopt in libc 5.4.20 sets __malloc_initialized to 1 now
 >> so that the gmalloc in xemacs doesn't get initialized.  Here is a
 >> short patch that fixed that on my system.
 >> 
 >> Will someone please try this out on a non-Linux box to see if
 >> breaks anything?

 David> 	No other file in the xemacs dist depends on this variable,
 David> so making it file local should be fine everywhere.

 David> 	The question is why mallopt is setting it to 1, I suspect
 David> this is because the gmalloc currently provided with xemacs is
 David> getting old. And mallopt is calling the new
 David> __malloc_initialize() routine.  If it is, and someone else is
 David> calling mallopt, then there is probably other potential for
 David> problems since the datastructures that mallopt is manipulating
 David> won't look as it expects.

 David> 	Why is mallopt being called?

Ok, I'm not sure this is exactly what is happening, but this is what
I've been able to figure out.

First call to malloc in gmalloc.c does this:
  if (__malloc_hook != NULL)
    return (*__malloc_hook) (size);

__malloc_hook is a call to a std lib call which is set to
__libc_mallopt which is just mallopt with a different name.  mallopt
then sets __malloc_hook to null and annoyingly sets
__malloc_initialize to 1 at the same time.

Jim


-- 
@James LewisMoss                 | moss@cs.sc.edu | Blessed Be!
@    http://www.cs.sc.edu/~moss  | dres@scsn.net  | Linux is cool!
@"Argue for your limitations and sure enough, they're yours." Bach

