From xemacs-m  Wed Apr 16 17:15:06 1997
Received: from atreides.eng.mindspring.net (atreides.eng.mindspring.net [207.69.183.11])
	by xemacs.org (8.8.5/8.8.5) with SMTP id RAA14990
	for <xemacs-beta@xemacs.org>; Wed, 16 Apr 1997 17:15:05 -0500 (CDT)
Received: (qmail 5384 invoked by uid 52477); 16 Apr 1997 22:07:56 -0000
To: xemacs-beta@xemacs.org
Subject: Re: The coreless crash phenomenon
References: <9704140220.AA02100@hrs102.rs.kyoto.omronsoft.co.jp> <m2k9m6ruhl.fsf@altair.xemacs.org> <m2encekl0d.fsf@bong.saar.de> <m2iv1phsib.fsf@altair.xemacs.org> <m2zpuz3mwy.fsf@bong.saar.de> <rvsp0repdp.fsf@sdnp5.ucsd.edu> <m2ybaj5bps.fsf_-_@bong.saar.de>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sj@eng.mindspring.net>
Date: 16 Apr 1997 18:07:36 -0400
In-Reply-To: Marc Aurel's message of 16 Apr 1997 15:38:55 +0200
Message-ID: <yviaybaizkn7.fsf@atreides.eng.mindspring.net>
Lines: 35
X-Mailer: Gnus v5.4.45/XEmacs 20.1(beta11)

Marc Aurel writes:
> Linux cracks: do I need to get rid of libc 5.4.13?  Could it be
> the reason for the critical instability of XEmacs on my system?

Dunno, but it's a good idea to go to 5.4.23.

I know a few people on this list use glibc v2 (aka libc.so.6).  Have
you got XEmacs configured with --use-system-malloc to work with
glibc-2.0.2?  

It crashes for me inside of regex_compile().  To be precise, that func 
uses GET_BUFFER_SPACE (34), which in turns expands to EXTEND_BUFFER.
EXTEND_BUFFER calls realloc(), which chokes inside of chunk_realloc()
deep inside libc (from memory).  The reason for choking is that the
arena inferred from the pointer passed in to realloc() points to
inaccessible memory.  I didn't dig further.  This was with b15 on my 
home machine. 

It works fine with the packaged malloc, of course.  Can gc cause
problems of this sort?  Problems with libc's realloc are another
possibility.  Glibc uses Doug Lea's malloc, albeit with some
extensions, and that's supposedly a robust implementation.  I'd like
to use glibc's malloc if possible.

Also, configuring with --use-system-malloc and libc 5.4.x leads to the
occasional "memory exhausted" error, as others have noted before.
These are perfectly harmless, since repeating the operation that
failed always works fine (for me, it's inevitably a `g' in Gnus, which
calls a make-vector that fails with that error).  I wonder if this
last problem manifests itself as a hard crash under glibc.

Sorry, no stack trace, coz it's a beta libc and you probably do not
care.

-Sudish

