unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* "/lib/ld-linux.so.2 /usr/bin/emacs" fails: "Memory exhausted"
@ 2005-11-11 19:57 Mark Seaborn
  2005-11-13 20:54 ` Richard M. Stallman
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Seaborn @ 2005-11-11 19:57 UTC (permalink / raw)


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 <davem@davemloft.net>

<http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/old/patch-2.6.10-rc3-bk14.log>

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

^ permalink raw reply	[flat|nested] 5+ messages in thread
[parent not found: <mailman.14913.1131738962.20277.bug-gnu-emacs@gnu.org>]

end of thread, other threads:[~2005-11-15  0:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-11 19:57 "/lib/ld-linux.so.2 /usr/bin/emacs" fails: "Memory exhausted" Mark Seaborn
2005-11-13 20:54 ` Richard M. Stallman
2005-11-15  0:34   ` Mark Seaborn
     [not found] <mailman.14913.1131738962.20277.bug-gnu-emacs@gnu.org>
2005-11-11 23:47 ` Romain Francoise
2005-11-14 13:38   ` Mark Seaborn

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).