From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#18505: 24.3.93; intermittent unexec failures when building on Mac OS X 10.10 beta, Xcode 6.0 Date: Sun, 21 Sep 2014 22:37:38 +0200 Message-ID: <6AC8F693-97B2-418C-ACEB-8324D6529AC6@swipnet.se> References: <541BAD75.9010701@porkrind.org> <541DC7EE.6080309@porkrind.org> <927680BE-0933-4F3E-AAAA-F2F3745F7D55@swipnet.se> <541F13FD.5010302@porkrind.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411331913 24372 80.91.229.3 (21 Sep 2014 20:38:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2014 20:38:33 +0000 (UTC) Cc: 18505-done@debbugs.gnu.org To: David Caldwell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 21 22:38:26 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XVntp-0004p3-4q for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Sep 2014 22:38:25 +0200 Original-Received: from localhost ([::1]:40873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVnto-0007IH-QI for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Sep 2014 16:38:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVntf-0007Gt-IU for bug-gnu-emacs@gnu.org; Sun, 21 Sep 2014 16:38:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XVntY-0001W6-FI for bug-gnu-emacs@gnu.org; Sun, 21 Sep 2014 16:38:15 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVntY-0001Um-Bw for bug-gnu-emacs@gnu.org; Sun, 21 Sep 2014 16:38:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XVntT-0000Hg-1l for bug-gnu-emacs@gnu.org; Sun, 21 Sep 2014 16:38:03 -0400 Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Sep 2014 20:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 18505 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Mail-Followup-To: 18505@debbugs.gnu.org, jan.h.d@swipnet.se, david@porkrind.org Original-Received: via spool by 18505-done@debbugs.gnu.org id=D18505.14113318651066 (code D ref 18505); Sun, 21 Sep 2014 20:38:02 +0000 Original-Received: (at 18505-done) by debbugs.gnu.org; 21 Sep 2014 20:37:45 +0000 Original-Received: from localhost ([127.0.0.1]:47710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XVntA-0000H7-Hv for submit@debbugs.gnu.org; Sun, 21 Sep 2014 16:37:45 -0400 Original-Received: from mailfe05.swip.net ([212.247.154.129]:39219 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XVnt7-0000Gx-JL for 18505-done@debbugs.gnu.org; Sun, 21 Sep 2014 16:37:43 -0400 X-T2-Spam-Status: No, hits=-0.5 required=5.0 tests=BAYES_05 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 529312266; Sun, 21 Sep 2014 22:37:39 +0200 In-Reply-To: <541F13FD.5010302@porkrind.org> X-Mailer: Apple Mail (2.1878.6) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:93590 Archived-At: Hi. 21 sep 2014 kl. 20:07 skrev David Caldwell : > On 9/21/14 2:15 AM, Jan Dj=E4rv wrote: >> Hello. >>=20 >> 20 sep 2014 kl. 20:31 skrev David Caldwell : >>=20 >>> On 9/20/14 8:31 AM, Jan Dj=E4rv wrote: >>>> Hello. >>>>=20 >>>> 19 sep 2014 kl. 06:13 skrev David Caldwell : >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I tried to build the latest pretest on Mac OS X Yosemite Beta with = the >>>>> new Xcode 6.0 (GM) tools and ran into this error during the unexec = step: >>>>>=20 >>>>> unexec: not enough room for load commands for new __DATA segments >>>>=20 >>>> Does it happen all the time or just some times? >>>=20 >>> It depends on 2 variables: the number of load commands that need to = be >>> added (num_unexec_regions) and text_seg_lowest_offset. >>>=20 >>> num_unexec_regions jumps around a lot, doing "make clean && make" = over >>> and over it'll be different every time. Somewhere between 12 and 34. >>=20 >> What makes it do that? Some address randomization? Some other = unknown bug? >> I would expect num_unexec_regions to be the same for every make. >=20 > I don't know. I would also expect num_unexec_regions to be the same. = If > it changes, it seems to mean the malloc behavior is different on every > run. But yes, perhaps address space randomization could cause that to > happen. I don't understand that part of the code well enough to > speculate too much. Me neither.=20 >=20 >> text_seg_lowest_offset could be address randomization, but if it = stays somewhat constant, that can't be it. >=20 > I just figured that out (and smacked my head because it was obvious). > That changed when I changed headerpad. I got curious and did a binary > search to figure out exactly how -headerpad affects > text_seg_lowest_offset in my setup (all number hex): >=20 > -headerpad text_seg_lowest_offset > 0 -> 740 17a0 > 741 -> 1740 27a0 > 1741 -> ??? 37a0 >=20 > So, text_seg_lowest_offset directly correlate with -headerpad and ld = is > doing some sort of alignment. Okay. >=20 >> I've seen this failure before, but usually a new make works. >> I'm trying to decide if this is emacs 24 or trunk material. >=20 > I think it should go in both. It's really quite a low-risk change: the > -headerpad option is well documented in ld, and the amount my patch = adds > gives an extra 1.5K of headroom on a 6M binary (.02%). >=20 > I did a bunch of 'bzr log' searches to understand the nature of the > -headerpad setting and it appears to not have been touched since 2006 > (in the 32 bit era). I believe that is why the comment in configure is > incorrect: load commands may have been 56 bytes on 32 bit archs, but > they are 78 bytes on my 64 bit computer (which is all current Macs = going > forward). I checked it in in the 24-branch. >=20 >> Is there a way to dynamically react to these changes and adjust = headerpad_extra dynamically at dump time? >=20 > Unfortunately the -headerpad is specified during link time so to = change > it dynamically would require re-linking after unexec-ing. That's a = large > Makefile change to get that all working correctly. And possibly overkill. Thanks, Jan D.