From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: James Van Artsdalen Newsgroups: gmane.emacs.bugs Subject: lim_data too narrow Date: Wed, 17 Dec 2003 18:58:55 -0600 (CST) Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <200312180058.hBI0wtaq054209@bigtex.jrv.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1071709634 2699 80.91.224.253 (18 Dec 2003 01:07:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2003 01:07:14 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 18 02:07:09 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AWmdB-0000qt-00 for ; Thu, 18 Dec 2003 02:07:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AWnTb-0002Lr-D3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Dec 2003 21:01:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AWnTR-0002Jf-Eo for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2003 21:01:09 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AWnSp-00022b-7c for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2003 21:01:02 -0500 Original-Received: from [24.73.246.106] (helo=bigtex.jrv.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AWnSo-0001z5-GA for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2003 21:00:30 -0500 Original-Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id hBI0wto8054212 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 17 Dec 2003 18:58:55 -0600 (CST) Original-Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id hBI0wtaq054209; Wed, 17 Dec 2003 18:58:55 -0600 (CST) Original-To: bug-gnu-emacs@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:6306 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:6306 This bug report will be sent to the Free Software Foundation, not to your local site managers!! Please write in English, because the Emacs maintainers do not have translators to read other languages for them. In GNU Emacs 21.3 (amd64--freebsd) lim_data is too narrow to hold the size of the process data segment. On my system (with 8 GB of RAM) the rlimit is by default (in KB): $ ulimit -d 8388608 lim_data needs to be at least as wide as the rlimit .rlim_cur field or truncation occurs. I'm not sure what the right cross-platform portable way to detect this situation is. The patch below is an example. Note that this change is not sufficient to build emacs for amd64. *** mem-limits.h.~1~ Wed Mar 8 12:49:46 2000 --- mem-limits.h Wed Dec 17 03:15:24 2003 *************** *** 98,104 **** static POINTER data_space_start; /* Number of bytes of writable memory we can expect to be able to get */ ! static unsigned long lim_data; #ifdef NO_LIM_DATA static void --- 98,104 ---- static POINTER data_space_start; /* Number of bytes of writable memory we can expect to be able to get */ ! static rlim_t lim_data; #ifdef NO_LIM_DATA static void