Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Jul 2004 12:18:13 -0400
From:      Andrew Heybey <ath@niksun.com>
To:        freebsd-ports@freebsd.org, mac@dmedia.ws
Subject:   Re: xemacs port on 5.2-CURRENT
Message-ID:  <20040720121813.4362a24a@stiegl.mj.niksun.com>

next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.

--Multipart=_Tue__20_Jul_2004_12_18_13_-0400_Z/NRld6V6hLT/Kc7
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> If there's a better place to send this, I'd be happy to do that. I've
> spent hours searching on Google and mailing lists for any related
> information, but have been unable to find any.
> 
> For the last several months (probably about 6-8) I've had problems
> with xemacs on 5.2-CURRENT that don't occur on my 4-STABLE boxes that
> are similarly configured. Every time xemacs starts up, it appears to
> be fine, but as soon as you try to do anything (like C-x C-f for
> example), it opens up a warning buffer and spews warnings like this at
> an alarming rate:
> 
> (254) (memory/critical) Warning: past acceptable memory limits
> Killing some buffers may delay running out of memory.
> However, certainly by the time you receive the 95% warning,
> you should clean up, kill this Emacs, and start a new one.
> 
> It continues to do that, even though everything continues to appear to
> operate normally. After a while (10 minutes to a few hours usually) it
> crashes completely, leaving a backtrace that doesn't have anything
> obviously helpful (to me).
> 
> I've checked my memory usage with top, etc., and everything appears to
> be just fine, with ~80MB free or more, and swap space untouched.
> 
> Has anyone else experienced similar problems? Do you know of any
> further steps I could take to try and resolve the issue?> 

It is not just in -CURRENT.  I just had the same problem after doing a
portupgrade of xemacs on my 4.9-RELEASE system.

Put the attached patch file in the editors/xemacs/files directory. 
The bug is that src/mem-limits.h is patched by the port to declare
the variable "lim_data" as type rlim_t (which is a 64-bit number) but
emacs.c still defines it as an int.  I am going to submit a PR.

andrew

--Multipart=_Tue__20_Jul_2004_12_18_13_-0400_Z/NRld6V6hLT/Kc7
Content-Type: text/plain;
 name="patch-emacs.c"
Content-Disposition: attachment;
 filename="patch-emacs.c"
Content-Transfer-Encoding: 7bit

--- src/emacs.c.orig	Wed Jan 15 07:18:00 2003
+++ src/emacs.c	Tue Jul 20 12:02:41 2004
@@ -344,7 +344,7 @@
 #endif
 
 /* Number of bytes of writable memory we can expect to be able to get */
-unsigned int lim_data;
+rlim_t lim_data;
 
 /* WARNING!
 

--Multipart=_Tue__20_Jul_2004_12_18_13_-0400_Z/NRld6V6hLT/Kc7--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040720121813.4362a24a>