bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell <svante.signell@gmail.com>]

On Wed, 2016-11-02 at 18:38 +0100, Svante Signell wrote:
> On Wed, 2016-11-02 at 18:46 +0200, Eli Zaretskii wrote:
...
> > The posted backtrace indicates the problem is with inability to
> > allocate memory:
> Yes!

More info: Forcing the use of SYSTEM_MALLOC instead of GNU_MALLOC and commenting
out sbrk usage in alloc.c and unexelf.c as in https://debbugs.gnu.org/cgi/bugrep
ort.cgi?bug=24892#15 temacs does no longer freak out (Killed). Looking at the
build log vm-limit.c and gmalloc.c are no longer compiled.

Now there is a SEGFAULT in dumped-emacs:

/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[4]: Entering directory '/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-
x/lisp'
  ELC      emacs-lisp/macroexp.elc
/bin/bash: line 1: 27157 Segmentation fault      EMACSLOADPATH=
'../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval "(setq max-
lisp-eval-depth 2200)" --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.el

I've traced it down to the make_float() function in alloc.c:
if (float_free_list = 0x0) <FALSE>
if (float_block_index=27 == FLOAT_BLOCK_SIZE=124): <FALSE>
Next statement: XSETFLOAT (val, &float_block->floats[float_block_index]);
is called with an invalid address:
(gdb) p float_block
$2 = (struct float_block *) 0xad8c00
(gdb) p *float_block
Cannot access memory at address 0xad8c00
causing the segfault later on.

Is the static struct float_block *float_block allocated on the heap?
0xad8c00 = 10.847 MiB is much smaller that available memory.