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

[Jason Duerstock]

I suspect the "right" solution to this is to define the "base" and
"mask" variables in ComputeRandomAllocationAddress() based on what
works for each architecture, but my enthusiasm for gathering that
information was pretty low at the time I ran into this, and hasn't
gone up much since then.
On Tue, Jul 3, 2018 at 7:54 PM Simon McVittie <smcv at debian.org> wrote:
>
> 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