Cannot build Emacs from source in container-based builds

[fmdkdd]

We provide a Makefile to build different Emacs versions from source in Travis. This is used by several Emacs package developers for their CI. It seems the Trusty update from December 12 prevents Emacs from compiling successfully.

Here is a failed build: https://travis-ci.org/flycheck/flycheck/jobs/328830034
Using the previous Trusty image, the build succeeds: https://travis-ci.org/flycheck/flycheck/builds/328992827

The build fails in the dumping phase:

Dumping under the name emacs
**************************************************
Warning: Your system has a gap between BSS and the
heap (25275672 bytes).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about
exec-shield in etc/PROBLEMS for more information.
**************************************************
/bin/bash: line 7: 10028 Segmentation fault      (core dumped) ./temacs --batch --load loadup bootstrap
make[2]: *** [bootstrap-emacs] Error 1
make[1]: *** [src] Error 2
make: *** [install_emacs] Error 2

Emacs can be a bit tricky to build from source. Here is the relevant section from etc/PROBLEMS:

*** Segfault during 'make'

If Emacs segfaults when 'make' executes one of these commands:

LC_ALL=C ./temacs -batch -l loadup bootstrap
LC_ALL=C ./temacs -batch -l loadup dump

the problem may be due to inadequate workarounds for address space
layout randomization (ASLR), an operating system feature that
randomizes the virtual address space of a process. ASLR is commonly
enabled in Linux and NetBSD kernels, and is intended to deter exploits
of pointer-related bugs in applications. If ASLR is enabled, the
command:

cat /proc/sys/kernel/randomize_va_space # GNU/Linux
sysctl security.pax.aslr.global # NetBSD

outputs a nonzero value.

These segfaults should not occur on most modern systems, because the
Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark
the Emacs executable as requiring non-randomized address space, and
Emacs uses the 'personality' system call to disable address space
randomization when dumping. However, older kernels may not support
'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a
secure computing mode (seccomp) that can be configured to disable the
'personality' call.

It may be possible to work around the 'personality' problem in a newer
Linux kernel by configuring seccomp to allow the 'personality' call.
For example, if you are building Emacs under Docker, you can run the
Docker container with a security profile that allows 'personality' by
using Docker's --security-opt option with an appropriate profile; see
https://docs.docker.com/engine/security/seccomp/.

To work around the ASLR problem in either an older or a newer kernel,
you can temporarily disable the feature while building Emacs. On
GNU/Linux you can do so using the following command (as root).

echo 0 > /proc/sys/kernel/randomize_va_space

You can re-enable the feature when you are done, by echoing the
original value back to the file. NetBSD uses a different command,
e.g., 'sysctl -w security.pax.aslr.global=0'.

Alternatively, you can try using the 'setarch' command when building
temacs like this, where -R disables address space randomization:

setarch $(uname -m) -R make

ASLR is not the only problem that can break Emacs dumping. Another
issue is that in Red Hat Linux kernels, Exec-shield is enabled by
default, and this creates a different memory layout. Emacs should
handle this at build time, but if this fails the following
instructions may be useful. Exec-shield is enabled on your system if

cat /proc/sys/kernel/exec-shield

prints a nonzero value. You can temporarily disable it as follows:

echo 0 > /proc/sys/kernel/exec-shield

As with randomize_va_space, you can re-enable Exec-shield when you are
done, by echoing the original value back to the file.

See also flycheck/emacs-travis#13.

[BanzaiMan]

Not sure what is going on here. If you would like to troubleshoot further, we are happy to enable the debug feature for your repo. Please email support@travis-ci.com.

[fmdkdd]

After further investigation, it appears that the December update is not the culprit. Using sudo: required on the latest Trusty works fine. It seems it's only container-based builds that have started failing, but worked fine until a few days ago.

Moreover, a fix to #9061 would probably fix this one as well, as this comment shows, it appears to be related to the personality syscall behavior changing under tighter security restructions on latest Docker versions.

(Also see moby/moby#22801)

I will close this one in favor of #9061. Running with sudo: required is fine for us for now.

Thank you for taking a look.

[andreas-roehler]

Seems running into the same issue here: https://travis-ci.org/andreas-roehler/emacs-UA