GNU bug report logs - #18505
24.3.93; intermittent unexec failures when building on Mac OS X 10.10 beta, Xcode 6.0

Previous Next

Package: emacs;

Reported by: David Caldwell <david <at> porkrind.org>

Date: Fri, 19 Sep 2014 04:15:03 UTC

Severity: normal

Tags: patch

Found in version 24.3.93

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 18505 <at> debbugs.gnu.org
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 11:15:26 +0200
Hello.

20 sep 2014 kl. 20:31 skrev David Caldwell <david <at> porkrind.org>:

> On 9/20/14 8:31 AM, Jan Djärv wrote:
>> Hello.
>> 
>> 19 sep 2014 kl. 06:13 skrev David Caldwell <david <at> porkrind.org>:
>> 
>>> Hello,
>>> 
>>> 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:
>>> 
>>> unexec: not enough room for load commands for new __DATA segments
>> 
>> Does it happen all the time or just some times?
> 
> It depends on 2 variables: the number of load commands that need to be
> added (num_unexec_regions) and text_seg_lowest_offset.
> 
> 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.

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.  text_seg_lowest_offset could be address randomization, but if it stays somewhat constant, that can't be it.

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.

Is there a way to dynamically react to these changes and adjust headerpad_extra dynamically at dump time?

> 
> text_seg_lowest_offset seems more stable, but it still changes. When I
> first unpacked the tarball and compiled, text_seg_lowest_offset was very
> low: 0x17c0. This stayed constant for about an hour while I was
> debugging this (adding debug prints) and then mysteriously jumped up to
> 0x24f0 at which point the unexec started succeeding without the change
> to headerpad_extra.
> 
> I just unpacked a clean pretest source directory and
> text_seg_lowest_offset was 0x17a0 and unexec failed.
> 
> Doing
>  (make clean && make) 2>&1 | grep "Lowest offset of all sections"
> over and over gives me:
> 
> Lowest offset of all sections in __TEXT segment:   0x17a0
> Lowest offset of all sections in __TEXT segment:   0x17a0
> Lowest offset of all sections in __TEXT segment:   0x17a0
> Lowest offset of all sections in __TEXT segment:   0x17a0
> Lowest offset of all sections in __TEXT segment:   0x17a0
> Lowest offset of all sections in __TEXT segment:   0x17a0
> 
> Though one of those times it didn't fail (presumably because
> num_unexec_regions was low enough).

	Jan D.







This bug report was last modified 10 years and 250 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.