From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd Date: Wed, 02 Nov 2016 18:46:06 +0200 Message-ID: <83fun9n835.fsf@gnu.org> References: <07351ee5-2e25-5a8b-0603-db4ad7458970@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1478105357 23733 195.159.176.226 (2 Nov 2016 16:49:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Nov 2016 16:49:17 +0000 (UTC) Cc: svante.signell@gmail.com, 24857@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 02 17:49:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1yiP-000246-MD for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Nov 2016 17:48:41 +0100 Original-Received: from localhost ([::1]:56400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1yiS-0003TE-Gz for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Nov 2016 12:48:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1ygs-0002Re-EW for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2016 12:47:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1ygo-0005k5-Gf for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2016 12:47:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53642) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1ygo-0005jr-Cf for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2016 12:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c1ygo-00031q-6h for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2016 12:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2016 16:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24857 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24857-submit@debbugs.gnu.org id=B24857.147810516411574 (code B ref 24857); Wed, 02 Nov 2016 16:47:02 +0000 Original-Received: (at 24857) by debbugs.gnu.org; 2 Nov 2016 16:46:04 +0000 Original-Received: from localhost ([127.0.0.1]:40808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1yfs-00030c-Ic for submit@debbugs.gnu.org; Wed, 02 Nov 2016 12:46:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1yfr-0002zt-J3 for 24857@debbugs.gnu.org; Wed, 02 Nov 2016 12:46:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1yfl-000597-Hk for 24857@debbugs.gnu.org; Wed, 02 Nov 2016 12:45:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1yfg-00055k-Aa; Wed, 02 Nov 2016 12:45:52 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4968 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c1yff-0004nl-5T; Wed, 02 Nov 2016 12:45:51 -0400 In-reply-to: <07351ee5-2e25-5a8b-0603-db4ad7458970@cs.ucla.edu> (message from Paul Eggert on Wed, 2 Nov 2016 08:20:59 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125273 Archived-At: > From: Paul Eggert > Date: Wed, 2 Nov 2016 08:20:59 -0700 > Cc: Svante Signell > > [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html] > > From: Svante Signell > 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 = 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?