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

[Eli Zaretskii <eliz@gnu.org>]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: 24857@debbugs.gnu.org
> Date: Thu, 10 Nov 2016 12:57:56 +0100
> 
> 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.

Sounds like the memory-related problems are not over yet.

Did you try to invoke temacs, and work in that?  IOW, try this:

  ./src/temacs -Q

It will load a bunch pf Lisp files, and should then present a normal
frame, where you should be able to work as usual.  If that does work
on Hurd, I'm pretty sure the problem is with unexec and dumping Emacs.