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

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18505 in the body.
You can then email your comments to 18505 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.93; intermittent unexec failures when building on Mac OS
 X 10.10 beta, Xcode 6.0
Date: Thu, 18 Sep 2014 21:13:41 -0700

[Message part 1 (text/plain, inline)]

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

(Full unexec log is attached).

Poking around I discovered a couple discrepancies. The "headerpad_extra"
setting in configure.ac says entries are 56 bytes, but they are actually
78 bytes (probably because the comment was originally written in the 32
bit days). Also the number of load commands needed is variable now--it
depends on how many malloc segments were found and how many it could
merge (see find_emacs_zone_regions() and unexec_regions_merge() in
unexmacosx.c).

I printed num_unexec_regions in unexmacosx.c and observed anywhere
from about 14 to 34 regions needed. But given that it seems to be
different on every run and it's super annoying to debug when you run out
of space, I suggest bumping headerpad_extra up to 0x1000. This gives
about 1.5KB of headroom (or wasted space, depending on how you look at
it) and allows for 52 load commands, which should be future proof for
quite a while. I have attached a patch for configure.ac that does this
and changes the comment to reflect my understanding.

I've also provided a patch that makes the unexec error more helpful: it
computes the size needed for headerpad_extra given the number of load
commands that it needed for that particular unexec run.

I assume this affects the trunk code, too, though I didn't look at it.

-David

[increase_headerpad_extra.patch (text/plain, attachment)]

[helpful_unexec_error.patch (text/plain, attachment)]

[unexec-log.txt (text/plain, attachment)]

[smime.p7s (application/pkcs7-signature, attachment)]

Message #8 received at 18505 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 18505 <at> debbugs.gnu.org
Subject: Re: bug#18505: 24.3.93;
 intermittent unexec failures when building on Mac OS X 10.10 beta,
 Xcode 6.0
Date: Sat, 20 Sep 2014 17:31:32 +0200

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?

	Jan D.

> 
> (Full unexec log is attached).
> 
> Poking around I discovered a couple discrepancies. The "headerpad_extra"
> setting in configure.ac says entries are 56 bytes, but they are actually
> 78 bytes (probably because the comment was originally written in the 32
> bit days). Also the number of load commands needed is variable now--it
> depends on how many malloc segments were found and how many it could
> merge (see find_emacs_zone_regions() and unexec_regions_merge() in
> unexmacosx.c).
> 
> I printed num_unexec_regions in unexmacosx.c and observed anywhere
> from about 14 to 34 regions needed. But given that it seems to be
> different on every run and it's super annoying to debug when you run out
> of space, I suggest bumping headerpad_extra up to 0x1000. This gives
> about 1.5KB of headroom (or wasted space, depending on how you look at
> it) and allows for 52 load commands, which should be future proof for
> quite a while. I have attached a patch for configure.ac that does this
> and changes the comment to reflect my understanding.
> 
> I've also provided a patch that makes the unexec error more helpful: it
> computes the size needed for headerpad_extra given the number of load
> commands that it needed for that particular unexec run.
> 
> I assume this affects the trunk code, too, though I didn't look at it.
> 
> -David
> <increase_headerpad_extra.patch><helpful_unexec_error.patch><unexec-log.txt>

Message #11 received at 18505 <at> debbugs.gnu.org (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 18505 <at> debbugs.gnu.org
Subject: Re: bug#18505: 24.3.93; intermittent unexec failures when
 building on Mac OS X 10.10 beta, Xcode 6.0
Date: Sat, 20 Sep 2014 11:31:10 -0700

[Message part 1 (text/plain, inline)]

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.

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).

-David

[smime.p7s (application/pkcs7-signature, attachment)]

Message #14 received at 18505 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 18505 <at> debbugs.gnu.org
Subject: Re: 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.

Message #17 received at 18505 <at> debbugs.gnu.org (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 18505 <at> debbugs.gnu.org
Subject: Re: 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:07:57 -0700

[Message part 1 (text/plain, inline)]

On 9/21/14 2:15 AM, Jan Djärv wrote:
> 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.

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.

> text_seg_lowest_offset could be address randomization, but if it stays somewhat constant, that can't be it.

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):

 -headerpad      text_seg_lowest_offset
   0 ->  740     17a0
 741 -> 1740     27a0
1741 -> ???      37a0

So, text_seg_lowest_offset directly correlate with -headerpad and ld is
doing some sort of alignment.

> 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.

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%).

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).

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

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.

-David

[smime.p7s (application/pkcs7-signature, attachment)]

Message #22 received at 18505-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 18505-done <at> debbugs.gnu.org
Subject: Re: 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

Hi.

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

> On 9/21/14 2:15 AM, Jan Djärv wrote:
>> 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.
> 
> 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. 

> 
>> text_seg_lowest_offset could be address randomization, but if it stays somewhat constant, that can't be it.
> 
> 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):
> 
> -headerpad      text_seg_lowest_offset
>   0 ->  740     17a0
> 741 -> 1740     27a0
> 1741 -> ???      37a0
> 
> So, text_seg_lowest_offset directly correlate with -headerpad and ld is
> doing some sort of alignment.

Okay.

> 
>> 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.
> 
> 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%).
> 
> 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.

> 
>> Is there a way to dynamically react to these changes and adjust headerpad_extra dynamically at dump time?
> 
> 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.

Previous Next

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