GNU bug report logs - #24708
25.1; Launching Emacs Under ld-linux.so Results in Memory Exhausted on Some Linuxes

Previous Next

Package: emacs;

Reported by: Nicolas Hafner <shinmera <at> tymoon.eu>

Date: Sun, 16 Oct 2016 16:32:02 UTC

Severity: normal

Tags: fixed

Found in version 25.1

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24708 in the body.
You can then email your comments to 24708 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#24708; Package emacs. (Sun, 16 Oct 2016 16:32:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas Hafner <shinmera <at> tymoon.eu>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 16 Oct 2016 16:32:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Hafner <shinmera <at> tymoon.eu>
To: bug-gnu-emacs <at> gnu.org
Cc: mordocai <at> mordocai.net
Subject: 25.1; Launching Emacs Under ld-linux.so Results in Memory Exhausted
 on Some Linuxes
Date: Sun, 16 Oct 2016 14:31:19 +0200
[Message part 1 (text/plain, inline)]
Attempting to run Emacs 25.1 with ld-linux.so under certain Linux
distributions will cause an immediate crash with a "Memory exhausted"
message. I can reproduce this consistently under Arch Linux (Kernel
4.8.1-1) and Debian Stretch (Kernel 4.6.0-1). However, Emacs launches
just fine with ld-linux under Linux Mint 17.1 (Kernel 3.13).

The command I'm using to run emacs like this is simply:
> /lib64/ld-linux-x86-64.so.2 /usr/bin/emacs

When running under GDB, the output is as follows:
> Starting program: /lib64/ld-linux-x86-64.so.2 /usr/bin/emacs
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> [New Thread 0x7fffe7f23700 (LWP 19205)]
> [New Thread 0x7fffe6efc700 (LWP 19206)]
> [New Thread 0x7fffe64cf700 (LWP 19207)]
>
> ***MEMORY-ERROR***: emacs[19201]: GSlice: failed to allocate 8176
bytes (alignment: 8192): Cannot allocate memory
>
>
> Thread 1 "ld-linux-x86-64" received signal SIGABRT, Aborted.
> 0x00007ffff0f4004f in raise () from /usr/lib/libc.so.6
> (gdb) backtrace
> #0  0x00007ffff0f4004f in raise () at /usr/lib/libc.so.6
> #1  0x00007ffff0f4147a in abort () at /usr/lib/libc.so.6
> #2  0x00007ffff58400f4 in  () at /usr/lib/libglib-2.0.so.0
> #3  0x00007ffff5840b19 in  () at /usr/lib/libglib-2.0.so.0
> #4  0x00007ffff5841668 in g_slice_alloc () at /usr/lib/libglib-2.0.so.0
> #5  0x00007ffff58416fe in g_slice_alloc0 () at /usr/lib/libglib-2.0.so.0
> #6  0x00007ffff5b212b4 in g_type_create_instance () at
/usr/lib/libgobject-2.0.so.0
> #7  0x00007ffff5b031fb in  () at /usr/lib/libgobject-2.0.so.0
> #8  0x00007ffff5b0510e in g_object_new_valist () at
/usr/lib/libgobject-2.0.so.0
> #9  0x00007ffff5b053b1 in g_object_new () at /usr/lib/libgobject-2.0.so.0
> #10 0x00000000004e4187 in  ()
> #11 0x0000000000009cc0 in  ()
> #12 0x000000000000b2b0 in  ()
> #13 0x00000000011f1c30 in  ()
> #14 0x00000000010bfcc3 in  ()
> #15 0x0000000000000000 in  ()

The only thing I've found related to this issue is a NEWS thread from
2005, though I am unsure as to how relevant this is for the current
problem.

<http://gnu.emacs.bug.narkive.com/6nDY0MRn/lib-ld-linux-so-2-usr-bin-emacs-fails-memory-exhausted>

The reason as to why I'm launching Emacs in this way is that I am
deploying cross-distribution portable packages of emacs that ship their
own versions of the shared libraries. In order for this to work I need
to ensure that the libraries are loaded from a custom folder, rather
than from the standard system directories. I need to invoke ld-linux.so
directly in order to do this.

Interestingly enough, if I build such a deployed package on the working
Linux Mint system --including all required shared libraries and
ld-linux.so in itself-- and copy it over to one of the other systems, it
launches just fine. Still, I would rather not have to potentially be
restricted to a build system that might break at any moment due to an
update to the Kernel or some other component that might trigger the bug.

If there's any other data that I could provide in order to help resolve
this issue, I would be more than happy to do what I can.

Sincerely, Nicolas Hafner



In GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.20.9)
 of 2016-09-18 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:    Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_CTYPE: en_GB.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=uim
  locale-coding-system: utf-8-unix

Major mode: REPL

Minor modes in effect:
  paredit-mode: t
  slime-trace-dialog-minor-mode: t
  slime-autodoc-mode: t
  slime-repl-map-mode: t
  slime-editing-mode: t
  my-keys-minor-mode: t
  company-quickhelp-mode: t
  global-company-mode: t
  company-mode: t
  openwith-mode: t
  global-linum-mode: t
  linum-mode: t
  delete-selection-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-mode: t
  global-ede-mode: t
  show-paren-mode: t
  ido-everywhere: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
../../usr/share/emacs/site-lisp/uim-el/uim.el: (lambda (x) ...) quoted
with ' rather than with #' [9 times]
‘epa-file’ already enabled
Polling "/tmp/slime.989" .. 1 (Abort with ‘M-x slime-abort-connection’.)
Starting new Ispell process /usr/bin/aspell with british dictionary...
Polling "/tmp/slime.989" .. 2 (Abort with ‘M-x slime-abort-connection’.)
For information about GNU Emacs and the GNU system, type C-h C-a.
Polling "/tmp/slime.989" .. 3 (Abort with ‘M-x slime-abort-connection’.)
Polling "/tmp/slime.989" .. 4 (Abort with ‘M-x slime-abort-connection’.)
Connecting to Swank on port 33717..
Connected. Hack and be merry!

Load-path shadows:
/home/linus/.emacs.d/elpa/cmake-mode-20160928.505/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/home/linus/.emacs.d/elpa/seq-2.16/seq hides
/usr/share/emacs/25.1/lisp/emacs-lisp/seq

Features:
(shadow sort mail-extr emacsbug message idna dired format-spec rfc822
mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader sendmail mail-utils neotree network-stream nsm starttls
flyspell ispell paredit company-oddmuse company-keywords company-etags
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-cmake company-xcode company-clang company-semantic
company-eclim company-template company-css company-nxml company-bbdb
shinmera-startup shinmera-js shinmera-haskell shinmera-matlab
shinmera-web shinmera-tex shinmera-eiffel slime-indentation
slime-cl-indent slime-hyperdoc url-http tls gnutls url url-proxy
url-privacy url-expand url-methods url-history mailcap url-auth
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-cookie url-domsuf
url-util url-parse auth-source gnus-util mm-util help-fns mail-prsvr
password-cache url-gw url-vars slime-sprof slime-asdf grep slime-fancy
slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree slime-scratch slime-presentations bridge
slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse
slime-company slime compile arc-mode archive-mode noutline outline pp
comint ansi-color hyperspec browse-url elisp-slime-nav etags xref
project ring cl-indent shinmera-lisp epa-file epa derived epg
shinmera-gpg shinmera-spell uim uim-helper uim-candidate uim-preedit
uim-key uim-util uim-debug uim-keymap uim-var uim-version shinmera-uim
shinmera-windows shinmera-paste shinmera-magit easy-mmode shinmera-keys
shinmera-neotree company-quickhelp pos-tip company edmacro kmacro
shinmera-company spolsky-theme openwith linum delsel semantic/db-mode
semantic/db semantic/idle semantic/format semantic/tag-ls semantic/find
semantic/ctxt semantic/util-modes semantic/util semantic semantic/tag
semantic/lex semantic/fw mode-local find-func ede/speedbar ede/files ede
ede/detect ede/base ede/auto ede/source eieio-base eieio-speedbar
speedbar sb-image ezimage dframe eieio-custom cl-seq wid-edit eieio
eieio-core cedet paren smex ido server powerline powerline-separators
color powerline-themes expand-region text-mode-expansions
er-basic-expansions expand-region-core expand-region-custom
multiple-cursors mc-hide-unmatched-lines-mode mc-separate-operations
rectangular-region-mode mc-mark-pop mc-mark-more thingatpt
mc-cycle-cursors mc-edit-lines multiple-cursors-core rect advice
shinmera-functions shinmera-general cl-macs cl shinmera-package
iso-transl shinmera-init shinmera finder-inf tex-site slime-autoloads
info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 318956 18913)
 (symbols 48 39383 0)
 (miscs 40 572 931)
 (strings 32 90618 11930)
 (string-bytes 1 2435217)
 (vectors 16 34591)
 (vector-slots 8 738263 2797)
 (floats 8 791 315)
 (intervals 56 821 59)
 (buffers 976 23))


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24708; Package emacs. (Tue, 05 Jun 2018 23:46:02 GMT) Full text and rfc822 format available.

Message #8 received at 24708 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Nicolas Hafner <shinmera <at> tymoon.eu>
Cc: mordocai <at> mordocai.net, 24708 <at> debbugs.gnu.org
Subject: Re: bug#24708: 25.1;
 Launching Emacs Under ld-linux.so Results in Memory Exhausted on Some
 Linuxes
Date: Tue, 05 Jun 2018 19:45:16 -0400
Nicolas Hafner <shinmera <at> tymoon.eu> writes:

> Attempting to run Emacs 25.1 with ld-linux.so under certain Linux
> distributions will cause an immediate crash with a "Memory exhausted"
> message. I can reproduce this consistently under Arch Linux (Kernel
> 4.8.1-1) and Debian Stretch (Kernel 4.6.0-1). However, Emacs launches
> just fine with ld-linux under Linux Mint 17.1 (Kernel 3.13).

Does still happen with Emacs 26.1?  There's been some changes to memory
allocater selection since then.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24708; Package emacs. (Wed, 06 Jun 2018 09:32:02 GMT) Full text and rfc822 format available.

Message #11 received at 24708 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Hafner <shinmera <at> tymoon.eu>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 24708 <at> debbugs.gnu.org
Subject: Re: bug#24708: 25.1; Launching Emacs Under ld-linux.so Results in
 Memory Exhausted on Some Linuxes
Date: Wed, 6 Jun 2018 11:31:24 +0200
[Message part 1 (text/plain, inline)]
I've tested it with 26.1 and indeed the problem seems to have been
fixed. Fantastic!


On 06/06/18 01:45, Noam Postavsky wrote:
> Nicolas Hafner <shinmera <at> tymoon.eu> writes:
>
>> Attempting to run Emacs 25.1 with ld-linux.so under certain Linux
>> distributions will cause an immediate crash with a "Memory exhausted"
>> message. I can reproduce this consistently under Arch Linux (Kernel
>> 4.8.1-1) and Debian Stretch (Kernel 4.6.0-1). However, Emacs launches
>> just fine with ld-linux under Linux Mint 17.1 (Kernel 3.13).
> Does still happen with Emacs 26.1?  There's been some changes to memory
> allocater selection since then.
>

[Message part 2 (text/html, inline)]
[signature.asc (application/pgp-signature, attachment)]

Added tag(s) fixed. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 06 Jun 2018 10:53:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 26.1, send any further explanations to 24708 <at> debbugs.gnu.org and Nicolas Hafner <shinmera <at> tymoon.eu> Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 06 Jun 2018 10:53:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 04 Jul 2018 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 7 years and 45 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.