From xemacs-m  Mon Jan 27 01:54:02 1997
Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id BAA14789 for <xemacs-beta@xemacs.org>; Mon, 27 Jan 1997 01:54:01 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.3/8.6.9) with SMTP id XAA05322 for <xemacs-beta@xemacs.org>; Sun, 26 Jan 1997 23:54:00 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id XAA01743; Sun, 26 Jan 1997 23:56:57 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta Mailing List <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> <hhn2tvy3l6.fsf@dres.elam.org>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
From: David Moore <dmoore@UCSD.EDU>
Date: 26 Jan 1997 23:56:56 -0800
In-Reply-To: James LewisMoss's message of 27 Jan 1997 02:33:41 -0500
Message-ID: <rvpvyr7dpz.fsf@sdnp5.ucsd.edu>
Lines: 51
X-Mailer: Red Gnus v0.80/XEmacs 19.15

James LewisMoss <dres@scsn.net> writes:

> >>>>> "David" == David Moore <dmoore@UCSD.EDU> writes:
>  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.


	Thanks.  This is fixed in the new version of gmalloc that I'm
trying to synch into xemacs.  Here's a patch on the gmalloc.c of
19.15b90 and 20.0b92 which I think is safer than the previous patch of
making __malloc_initialized file local.  It'll be a while before I can
finish the complete gmalloc synch, as it affects quite a few places.

	Can people try this out and see if it works for them on both the
linux machines w/ the problem and on any other architecture?

--- gmalloc.c.orig	Sun Jan 26 23:51:29 1997
+++ gmalloc.c	Sun Jan 26 23:54:34 1997
@@ -556,12 +556,12 @@
     return NULL;
 #endif
 
-  if (__malloc_hook != NULL)
-    return (*__malloc_hook) (size);
-
   if (!__malloc_initialized)
     if (!initialize ())
       return NULL;
+
+  if (__malloc_hook != NULL)
+    return (*__malloc_hook) (size);
 
 #ifdef SUNOS_LOCALTIME_BUG
   /* Workaround for localtime() allocating 8 bytes and writing 9 bug... */

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

