Bug#902961: mozjs52: FTBFS in recent unstable: ReserveProcessExecutableMemory() fails during tests

[Simon McVittie]

Source: mozjs52
Version: 52.3.1-8
Severity: serious
Justification: fails to build from source (but built successfully in the past)

(X-Debbugs-Cc to contributors to #897178, to which this seems related,
and #902197)

After fixing #902197, the mozjs52 build-time tests failed on the amd64
Debian porterbox barriere. Specifically, the smoke-test in debian/test.sh
that's run before trying the actual test suite:

    "$SRCDIR/js/src/js" -e 'print("Hello, world")'

fails, with js exiting 1.

Running it under gdb reveals that this is because
ReserveProcessExecutableMemory() in js/src/jit/ProcessExecutableMemory.cpp
fails during startup, causing JS_Init() to fail. js helpfully has no
diagnostics at all for this, it just silently exits with EXIT_FAILURE.
(Ignore the first implementation of ReserveProcessExecutableMemory(),
which is for Windows; the Unix implementation is around line 300.)

That function gets a random address, and passes it as the first argument
of mmap(., 1 gigabyte, PROT_NONE, MAP_PRIVATE | MAP_ANON, -1, 0) on
64-bit machines, or the same but with 128M instead of 1G on 32-bit.
This now seems to be failing and returning NULL.

I was surprised to find that on the same machine, if I install gjs (a
GNOME wrapper around mozjs) and the slightly older mozjs 52.3.1-7 that it
depends on, gjs-console -c 'print("hello")' works OK. (We don't package
mozjs' own command-line tool 'js' any more, so no precompiled copy is
available.) The changes between 52.3.1-7 and what I'm compiling all seem
to be specific to non-amd64 architectures, so maybe this is about the
environment in which mozjs was built, rather than the source code used?

A hack that works to avoid this is to retry the mmap() without the address
hint, like in Jason Duerstock's debian/patches/ia64-support.patch,
but for non-IA64 architectures as well; see attached. I suspect this
might be the wrong solution, but perhaps it points someone who knows
this better than I do in the direction of a better solution...

This also makes me wonder whether the failure addressed by
ia64-support.patch was in fact a generic issue with newer $something
(kernel? compiler? dpkg-buildflags?), which happened to only be seen
by ia64 porters because everyone else was compiling and testing mozjs52
with an older $something?

    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: If-executable-memory-can-t-be-mapped-retry-without-random.patch
Type: text/x-diff
Size: 1160 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20180704/d5fc9d29/attachment.patch>