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

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 2 Nov 2016 08:20:59 -0700
> Cc: Svante Signell <svante.signell@gmail.com>
> 
> [forwarded from 
> http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html]
> 
> From: Svante Signell <svante.signell@gmail.com>
> To: emacs-devel@gnu.org
> Date: Wed, 02 Nov 2016 15:16:54 +0100
> 
> Since a long time emacs FTBFS due to unknown reasons. The latest version
> building was Debian 24.5+1-5, from 27 Nov 2015. Even before successful builds
> were by pure luck. One suspicious issue is that emacs use sbrk() for memory
> allocation, right? Notably sbrk() is not fool-proof as implemented for Hurd in
> glibc. Use of sbrk is found in files alloc.c, unexelf.c and gmalloc.c, which 
> are
> all compiled. Avoiding compilation of ralloc.c with 0001-Default-REL_ALLOC-to-
> no.patch did not improve the situation.

The posted backtrace indicates the problem is with inability to
allocate memory:

  #374452 0x0521d7bf in __assert_perror_fail (errnum=1073741836, file=0x516d8f0 
"../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c 
<__PRETTY_FUNCTION__.9436> "_init_routine") at assert-perr.c:35
          errbuf = 
"\001\000\000\000\300r\375\001@\311\002\001'\336\000\000\360\333\000\000Ð\225\000\000\240\061\035\005\240\061\035\005\001\000\000\000\024\312\002\001\000
 
\000\000\000\000\000\000\001\000\000\000v\032i\t\000\000\000\000\000\000\000\000\251\224\000\000\000\260\002\000\f\001\034\005\330\310\350\004\236\002\000\000Ë\235\000\000\005\000\000\000\001\000\000\000$I\034\005\020\225\000\000\310/\374\a;\316\034\005$\312\002\001
 \312\002\001\000 
\000\000\310\f\004\b}\000\000\000;\316\034\005\223\365\034\005j\315yy\251\224\000\000\000\260\002\000<\020\374\ax\204\336\a\375\000\000\000Ë\235\000\000\005\000\000\000\001\000\000\000d!\374\aÐ\225\000\000\255\062\035\005\255\062\035\005t\312\002\001p\312\002\001\240\061\035\005"...
          e = 0x53646db "Cannot allocate memory"
  #374453 0x0516bb99 in _init_routine (stack=0x0) at 
../libpthread/sysdeps/mach/hurd/pt-sysdep.c:67
          thread = 0x0
          err = <optimized out>
          attr = {__schedparam = {__sched_priority = 0}, __stackaddr = 0x7, 
__stacksize = 1, __guardsize = 85910395, __detachstate = (unknown: 87916512), 
__inheritsched = (unknown: 3084914), __contentionscope = (unknown: 1866732), 
__schedpolicy = 85375740}
          attrp = 0x0
  #374454 0x05210a33 in init (data=0x102cdf0) at 
../sysdeps/mach/hurd/i386/init-first.c:213

Btw, what happened between frame #0 and frame #374454?  Was that some
infinite loop trying to print an error message, which caused an
attempt to allocate memory, which tried to print an error message, and
so on and so forth?