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: "/lib/ld-linux.so.2 /usr/bin/emacs" fails: "Memory exhausted" Date: Fri, 11 Nov 2005 19:57:52 +0000 (GMT) Message-ID: <20051111.195752.730551918.mrs@localhost> 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 1131739020 29354 80.91.229.2 (11 Nov 2005 19:57:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2005 19:57:00 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 11 20:56:58 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Eaf0E-0005lS-J6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2005 20:56:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eaf0D-0003SI-Kv for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2005 14:56:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Eaf0C-0003SD-EP for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2005 14:56:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Eaf0A-0003S1-LZ for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2005 14:56:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eaf0A-0003Ry-Hn for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2005 14:55:58 -0500 Original-Received: from [212.67.120.103] (helo=perdition3.onetel.net.uk) by monty-python.gnu.org with smtp (Exim 4.34) id 1Eaf0A-0006yv-Ll for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2005 14:55:58 -0500 Original-Received: (qmail 29596 invoked from network); 11 Nov 2005 19:56:20 -0000 Original-Received: from unknown (HELO 213-78-171-168.ppp.onetel.net.uk) (213.78.171.168) by perd3 with SMTP; 11 Nov 2005 19:56:20 -0000 Original-Received: from 127.0.0.1 by somecomputer.somewhere with esmtp (MasqMail 0.1.13) id 1Eaf20-0fp-00 for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2005 19:57:52 +0000 Original-To: bug-gnu-emacs@gnu.org 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:14013 Archived-At: The problem can be summarised very simply: $ /lib/ld-linux.so.2 /usr/bin/emacs Memory exhausted--use M-x save-some-buffers RET $ emacs --version GNU Emacs 21.4.1 ... In other words, starting GNU Emacs by invoking the dynamic linker doesn't work, and fails pretty quickly with an incorrect out-of-memory error. This is on i386. This is the first program I've seen that fails when starting using the dynamic linker this way. I would like this to work because Plash (http://plash.beasts.org) launches programs this way. The only reference to this problem that I have seen is a note in a Linux kernel patch: [SPARC]: Adjust 32-bit ELF_ET_DYN_BASE. We were using 0x08000000 instead of TASK_UNMAPPED_BASE so that running something like "/lib/ld-linux.so.2 emacs" would work. The issue there was that wherever /lib/ld-linux.so.2 gets mapped (controlled by ELF_ET_DYN_BASE), that is where the BSS start for the process ends up. Now, emacs allocates dynamic memory for LISP objects from the BSS, and needs the top 4 bits of the virtual address to be clear so that it can encode LISP type and GC marking information there. But making this obscure emacs case work breaks lots of other stuff. For example, programs with a reasonably large data section fail to load via direct ld.so interpreter execution because the data section is large enough to begin overlapping with the ELF_ET_DYN_BASE area. The /lib/ld-linux.so.2 emacs case does not work on a lot of platforms due to this issue, including i386, so it is not worth making work on sparc either. It is indeed useful sometimes when debugging a new experimental build of glibc for example, but people doing that can hack the value of ELF_ET_DYN_BASE in their kernels. Perhaps at some point we will make a sysctl controllable value. Signed-off-by: David S. Miller I don't fully understand this. Starting programs through /lib/ld-linux.so.2 does not appear to change the addresses at which object files get mapped. Do you know what the problem is and whether it is simple to fix? For comparison, XEmacs does not have this problem. Cheers, Mark