From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Seaborn Newsgroups: gmane.emacs.bugs Subject: Re: "/lib/ld-linux.so.2 /usr/bin/emacs" fails: "Memory exhausted" Date: Mon, 14 Nov 2005 13:38:19 +0000 (GMT) Message-ID: <20051114.133819.846939628.mrs@localhost> References: <87iruyhhms.fsf@pacem.orebokech.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1131979242 2966 80.91.229.2 (14 Nov 2005 14:40:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2005 14:40:42 +0000 (UTC) Cc: romain@orebokech.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 14 15:40:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EbfUH-0005tz-3s for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2005 15:39:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EbfUD-0000PM-Ie for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2005 09:39:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EbeVd-0002X1-D7 for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2005 08:36:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EbeVb-0002Vg-AS for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2005 08:36:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EbeVa-0002VH-Jk for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2005 08:36:31 -0500 Original-Received: from [212.67.120.102] (helo=perdition2.onetel.net.uk) by monty-python.gnu.org with smtp (Exim 4.34) id 1EbeVa-0001g5-IA for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2005 08:36:30 -0500 Original-Received: (qmail 2118 invoked from network); 14 Nov 2005 13:39:52 -0000 Original-Received: from unknown (HELO 213-78-87-120.ppp.onetel.net.uk) (213.78.87.120) by perd2 with SMTP; 14 Nov 2005 13:39:52 -0000 Original-Received: from 127.0.0.1 by somecomputer.somewhere with esmtp (MasqMail 0.1.13) id 1EbeXL-0Vp-00; Mon, 14 Nov 2005 13:38:19 +0000 Original-To: bug-gnu-emacs@gnu.org In-Reply-To: <87iruyhhms.fsf@pacem.orebokech.com> X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:14070 Archived-At: Romain Francoise wrote: > Mark Seaborn writes: > > > Do you know what the problem is and whether it is simple to fix? > > I can reproduce this problem with Emacs 21.4 but not with the CVS > version, so it's been fixed already. It's hard to tell which change > fixed it, since the Emacs 21 and Emacs 22 codebases have diverged > significantly in the 4 years that have passed since the 21.1 release. Thanks for checking. It turned out that I was wrong, and the use of address space does change when you invoke ld-linux.so.2 directly: brk() changes where it allocates memory from. So I can fill in the gaps from the description I posted before. brk() starts allocating from after the BSS (zero-initialised) segment of the executable that was invoked by exec(). For normal executables this is after 0x08000000. ld-linux.so.2 gets loaded at 0x80000000, so brk() follows from somewhere after that (regardless of what executable ld-linux.so.2 subsequently loads). Emacs allocates memory using malloc(), which uses brk(), and so it gets an address with one of the top 4 bits set, which it can't handle. I would guess that Emacs' use of the top 4 bits hasn't changed but rather Emacs 22 uses mmap() to allocate memory rather than malloc(). I suppose Emacs 21 could be fixed to use mmap() rather than malloc(), though I don't know whether you'd want to make a change like that in the stable branch. For running programs under Plash, I could change libc's behaviour so that malloc() uses mmap() rather than brk(), which would then work with any version of Emacs. Mark