Let me start by saying I just checked out the Swift repos yesterday, and although i’ve looked at a little code and done some of the basic setup steps, this is pretty new to me, and I could easily be doing something wrong.
Having said that, I wanted to set up Xcode so I could make a change, but when I run build-script -x, it goes for a while and then just seems to freeze — cpu usage drops off and nothing further seems to happen. I have let it sit for maybe ten minutes, but not hours.
It is currently frozen in this section:
=== BUILD AGGREGATE TARGET add_custom_command_target-b646e880e18661860c3d95b53adeee18-ExistentialCollection.swift OF PROJECT Swift WITH CONFIGURATION Debug ===
After this line:
cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core && /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test -DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt -DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt -DCMAKE_SIZEOF_VOID_P=8 -o /Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/ExistentialCollection.swift.tmp ExistentialCollection.swift.gyb
If I break and run it again, it seems to do roughly the same thing and freeze again with slightly different information:
=== BUILD AGGREGATE TARGET add_custom_command_target-c5582f2ec66110e6e1b09a999368ab26-Slice.swift OF PROJECT Swift WITH CONFIGURATION Debug ===
Wanted to share I encountered this issue on 5/11.
(Ninja build was+is fine.)
Maybe the first 8 gyb scripts to run (I’m on a 2012 Mac Mini) are not recognized as having finished…
As you suggest, CPU of xcodebuild, cmake, and python processes were all 0.
Regards,
Will Stanton
···
On May 20, 2016, at 9:44 AM, Geoffrey Wiseman via swift-dev <swift-dev@swift.org> wrote:
Hey,
Let me start by saying I just checked out the Swift repos yesterday, and although i’ve looked at a little code and done some of the basic setup steps, this is pretty new to me, and I could easily be doing something wrong.
Having said that, I wanted to set up Xcode so I could make a change, but when I run build-script -x, it goes for a while and then just seems to freeze — cpu usage drops off and nothing further seems to happen. I have let it sit for maybe ten minutes, but not hours.
It is currently frozen in this section:
=== BUILD AGGREGATE TARGET add_custom_command_target-b646e880e18661860c3d95b53adeee18-ExistentialCollection.swift OF PROJECT Swift WITH CONFIGURATION Debug ===
After this line:
cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core && /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test -DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt -DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt -DCMAKE_SIZEOF_VOID_P=8 -o /Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/ExistentialCollection.swift.tmp ExistentialCollection.swift.gyb
If I break and run it again, it seems to do roughly the same thing and freeze again with slightly different information:
=== BUILD AGGREGATE TARGET add_custom_command_target-c5582f2ec66110e6e1b09a999368ab26-Slice.swift OF PROJECT Swift WITH CONFIGURATION Debug ===
I ran build-script -x a few days ago. It didn't freeze, but it did take
several hours to complete (on a late-model 13" MBP).
Austin
···
On Fri, May 20, 2016 at 2:28 PM, Will Stanton via swift-dev < swift-dev@swift.org> wrote:
Hi Geoffrey,
Wanted to share I encountered this issue on 5/11.
(Ninja build was+is fine.)
Maybe the first 8 gyb scripts to run (I’m on a 2012 Mac Mini) are not
recognized as having finished…
As you suggest, CPU of xcodebuild, cmake, and python processes were all 0.
Regards,
Will Stanton
> On May 20, 2016, at 9:44 AM, Geoffrey Wiseman via swift-dev < > swift-dev@swift.org> wrote:
>
> Hey,
>
> Let me start by saying I just checked out the Swift repos yesterday, and
although i’ve looked at a little code and done some of the basic setup
steps, this is pretty new to me, and I could easily be doing something
wrong.
>
> Having said that, I wanted to set up Xcode so I could make a change, but
when I run build-script -x, it goes for a while and then just seems to
freeze — cpu usage drops off and nothing further seems to happen. I have
let it sit for maybe ten minutes, but not hours.
>
> It is currently frozen in this section:
> === BUILD AGGREGATE TARGET
add_custom_command_target-b646e880e18661860c3d95b53adeee18-ExistentialCollection.swift
OF PROJECT Swift WITH CONFIGURATION Debug ===
>
> After this line:
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core &&
/Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test
-DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=8 -o
/Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/ExistentialCollection.swift.tmp
ExistentialCollection.swift.gyb
>
> If I break and run it again, it seems to do roughly the same thing and
freeze again with slightly different information:
>
> === BUILD AGGREGATE TARGET
add_custom_command_target-c5582f2ec66110e6e1b09a999368ab26-Slice.swift OF
PROJECT Swift WITH CONFIGURATION Debug ===
>
> …
>
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core &&
/Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test
-DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=8 -o
/Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/Slice.swift.tmp
Slice.swift.gyb
>
> Any thoughts / suggestions? —verbose-build doesn’t seem to add any
useful information. Something I’m doing?
>
Hypotheses:
- There are several executables that get linked around the same time (swiftc, swift-ide-test, sil-opt, etc), which leads to swapping.
- Building the standard library with a debug compiler is really slow.
- There’s actually a bug here somewhere, possibly due to a newer version of CMake, or possibly due to xcodebuild, or even maybe the OS making bad scheduling decisions.
For the record, I build with Xcode fairly regularly, but my normal workflow is to generate the Xcode projects, build LLVM, and work in Xcode…but then do a release+asserts build with ninja. I’ll save the Xcode-side build for when I actually want a debug compiler or debug stdlib.
Jordan
···
On May 20, 2016, at 14:36, Austin Zheng via swift-dev <swift-dev@swift.org> wrote:
I ran build-script -x a few days ago. It didn't freeze, but it did take several hours to complete (on a late-model 13" MBP).
Austin
On Fri, May 20, 2016 at 2:28 PM, Will Stanton via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Hi Geoffrey,
Wanted to share I encountered this issue on 5/11.
(Ninja build was+is fine.)
Maybe the first 8 gyb scripts to run (I’m on a 2012 Mac Mini) are not recognized as having finished…
As you suggest, CPU of xcodebuild, cmake, and python processes were all 0.
Regards,
Will Stanton
> On May 20, 2016, at 9:44 AM, Geoffrey Wiseman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>
> Hey,
>
> Let me start by saying I just checked out the Swift repos yesterday, and although i’ve looked at a little code and done some of the basic setup steps, this is pretty new to me, and I could easily be doing something wrong.
>
> Having said that, I wanted to set up Xcode so I could make a change, but when I run build-script -x, it goes for a while and then just seems to freeze — cpu usage drops off and nothing further seems to happen. I have let it sit for maybe ten minutes, but not hours.
>
> It is currently frozen in this section:
> === BUILD AGGREGATE TARGET add_custom_command_target-b646e880e18661860c3d95b53adeee18-ExistentialCollection.swift OF PROJECT Swift WITH CONFIGURATION Debug ===
>
> After this line:
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core && /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test -DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt -DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt -DCMAKE_SIZEOF_VOID_P=8 -o /Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/ExistentialCollection.swift.tmp ExistentialCollection.swift.gyb
>
> If I break and run it again, it seems to do roughly the same thing and freeze again with slightly different information:
>
> === BUILD AGGREGATE TARGET add_custom_command_target-c5582f2ec66110e6e1b09a999368ab26-Slice.swift OF PROJECT Swift WITH CONFIGURATION Debug ===
>
> …
>
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core && /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test -DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt -DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt -DCMAKE_SIZEOF_VOID_P=8 -o /Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/Slice.swift.tmp Slice.swift.gyb
>
> Any thoughts / suggestions? —verbose-build doesn’t seem to add any useful information. Something I’m doing?
>
I've experienced this multiple times in the past, and I'm seeing it today.
Does anyone have thoughts on how this might be root-caused/fixed?
···
On Fri, May 20, 2016 at 7:12 PM, Jordan Rose via swift-dev < swift-dev@swift.org> wrote:
Hypotheses:
- There are several executables that get linked around the same time
(swiftc, swift-ide-test, sil-opt, etc), which leads to swapping.
- Building the standard library with a debug compiler is really slow.
- There’s actually a bug here somewhere, possibly due to a newer version
of CMake, or possibly due to xcodebuild, or even maybe the OS making bad
scheduling decisions.
For the record, I build with Xcode fairly regularly, but my normal
workflow is to generate the Xcode projects, build LLVM, and work in
Xcode…but then do a release+asserts build with ninja. I’ll save the
Xcode-side build for when I actually want a debug compiler or debug stdlib.
Jordan
On May 20, 2016, at 14:36, Austin Zheng via swift-dev <swift-dev@swift.org> > wrote:
I ran build-script -x a few days ago. It didn't freeze, but it did take
several hours to complete (on a late-model 13" MBP).
Austin
On Fri, May 20, 2016 at 2:28 PM, Will Stanton via swift-dev < > swift-dev@swift.org> wrote:
Hi Geoffrey,
Wanted to share I encountered this issue on 5/11.
(Ninja build was+is fine.)
Maybe the first 8 gyb scripts to run (I’m on a 2012 Mac Mini) are not
recognized as having finished…
As you suggest, CPU of xcodebuild, cmake, and python processes were all 0.
Regards,
Will Stanton
> On May 20, 2016, at 9:44 AM, Geoffrey Wiseman via swift-dev < >> swift-dev@swift.org> wrote:
>
> Hey,
>
> Let me start by saying I just checked out the Swift repos yesterday,
and although i’ve looked at a little code and done some of the basic setup
steps, this is pretty new to me, and I could easily be doing something
wrong.
>
> Having said that, I wanted to set up Xcode so I could make a change,
but when I run build-script -x, it goes for a while and then just seems to
freeze — cpu usage drops off and nothing further seems to happen. I have
let it sit for maybe ten minutes, but not hours.
>
> It is currently frozen in this section:
> === BUILD AGGREGATE TARGET
add_custom_command_target-b646e880e18661860c3d95b53adeee18-ExistentialCollection.swift
OF PROJECT Swift WITH CONFIGURATION Debug ===
>
> After this line:
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core
&& /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test
-DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=8 -o
/Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/ExistentialCollection.swift.tmp
ExistentialCollection.swift.gyb
>
> If I break and run it again, it seems to do roughly the same thing and
freeze again with slightly different information:
>
> === BUILD AGGREGATE TARGET
add_custom_command_target-c5582f2ec66110e6e1b09a999368ab26-Slice.swift OF
PROJECT Swift WITH CONFIGURATION Debug ===
>
> …
>
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core
&& /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test
-DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=8 -o
/Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/Slice.swift.tmp
Slice.swift.gyb
>
> Any thoughts / suggestions? —verbose-build doesn’t seem to add any
useful information. Something I’m doing?
>
Actually, I think this was a Python problem for me. I had installed Python
via Homebrew — running "brew unlink python" before a build-script
invocation made it work fine.
Jacob
···
On Wed, May 25, 2016 at 7:59 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
I've experienced this multiple times in the past, and I'm seeing it today.
Does anyone have thoughts on how this might be root-caused/fixed?
On Fri, May 20, 2016 at 7:12 PM, Jordan Rose via swift-dev < > swift-dev@swift.org> wrote:
Hypotheses:
- There are several executables that get linked around the same time
(swiftc, swift-ide-test, sil-opt, etc), which leads to swapping.
- Building the standard library with a debug compiler is really slow.
- There’s actually a bug here somewhere, possibly due to a newer version
of CMake, or possibly due to xcodebuild, or even maybe the OS making bad
scheduling decisions.
For the record, I build with Xcode fairly regularly, but my normal
workflow is to generate the Xcode projects, build LLVM, and work in
Xcode…but then do a release+asserts build with ninja. I’ll save the
Xcode-side build for when I actually want a debug compiler or debug stdlib.
Jordan
On May 20, 2016, at 14:36, Austin Zheng via swift-dev < >> swift-dev@swift.org> wrote:
I ran build-script -x a few days ago. It didn't freeze, but it did take
several hours to complete (on a late-model 13" MBP).
Austin
On Fri, May 20, 2016 at 2:28 PM, Will Stanton via swift-dev < >> swift-dev@swift.org> wrote:
Hi Geoffrey,
Wanted to share I encountered this issue on 5/11.
(Ninja build was+is fine.)
Maybe the first 8 gyb scripts to run (I’m on a 2012 Mac Mini) are not
recognized as having finished…
As you suggest, CPU of xcodebuild, cmake, and python processes were all
0.
Regards,
Will Stanton
> On May 20, 2016, at 9:44 AM, Geoffrey Wiseman via swift-dev < >>> swift-dev@swift.org> wrote:
>
> Hey,
>
> Let me start by saying I just checked out the Swift repos yesterday,
and although i’ve looked at a little code and done some of the basic setup
steps, this is pretty new to me, and I could easily be doing something
wrong.
>
> Having said that, I wanted to set up Xcode so I could make a change,
but when I run build-script -x, it goes for a while and then just seems to
freeze — cpu usage drops off and nothing further seems to happen. I have
let it sit for maybe ten minutes, but not hours.
>
> It is currently frozen in this section:
> === BUILD AGGREGATE TARGET
add_custom_command_target-b646e880e18661860c3d95b53adeee18-ExistentialCollection.swift
OF PROJECT Swift WITH CONFIGURATION Debug ===
>
> After this line:
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core
&& /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test
-DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=8 -o
/Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/ExistentialCollection.swift.tmp
ExistentialCollection.swift.gyb
>
> If I break and run it again, it seems to do roughly the same thing and
freeze again with slightly different information:
>
> === BUILD AGGREGATE TARGET
add_custom_command_target-c5582f2ec66110e6e1b09a999368ab26-Slice.swift OF
PROJECT Swift WITH CONFIGURATION Debug ===
>
> …
>
> cd /Users/geoffrey/dev/work/opensource/swift/swift/stdlib/public/core
&& /Users/geoffrey/dev/work/opensource/swift/swift/utils/gyb --test
-DunicodeGraphemeBreakPropertyFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/Users/geoffrey/dev/work/opensource/swift/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=8 -o
/Users/geoffrey/dev/work/opensource/swift/build/Xcode-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/Slice.swift.tmp
Slice.swift.gyb
>
> Any thoughts / suggestions? —verbose-build doesn’t seem to add any
useful information. Something I’m doing?
>
As soon as I read this, I thought I should probably try — many of my dev tools are brew-installed, so it was worth a shot.
It worked. Brew unlink, and suddenly the build script completes. Some interaction between the build script and other versions/installations of Python, I guess.
- Geoffrey
···
On May 26, 2016, at 1:20 AM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
Actually, I think this was a Python problem for me. I had installed Python via Homebrew — running "brew unlink python" before a build-script invocation made it work fine.
Can someone who can reproduce this issue please file a bug on bugs.swift.org with as much information as possible about what exactly is hanging?
- Daniel
···
On May 26, 2016, at 10:53 AM, Geoffrey Wiseman via swift-dev <swift-dev@swift.org> wrote:
On May 26, 2016, at 1:20 AM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Actually, I think this was a Python problem for me. I had installed Python via Homebrew — running "brew unlink python" before a build-script invocation made it work fine.
As soon as I read this, I thought I should probably try — many of my dev tools are brew-installed, so it was worth a shot.
It worked. Brew unlink, and suddenly the build script completes. Some interaction between the build script and other versions/installations of Python, I guess.
On Thu, May 26, 2016 at 10:56 AM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
Can someone who can reproduce this issue please file a bug on
bugs.swift.org with as much information as possible about what exactly is
hanging?
- Daniel
On May 26, 2016, at 10:53 AM, Geoffrey Wiseman via swift-dev < > swift-dev@swift.org> wrote:
On May 26, 2016, at 1:20 AM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
Actually, I think this was a Python problem for me. I had installed Python
via Homebrew — running "brew unlink python" before a build-script
invocation made it work fine.
As soon as I read this, I thought I should probably try — many of my dev
tools are brew-installed, so it was worth a shot.
It worked. Brew unlink, and suddenly the build script completes. Some
interaction between the build script and other versions/installations of
Python, I guess.
I have no involvement in this, but does the build script call / use lldb at some point? I have an outstanding bug (rdar://25314779) that lldb (for its internal use) uses the first Python interpreter in the path, instead of hard-coding the Apple provided system Python (which in my case then leads to missing modules that lldb relies on that are not part of the Homebrew Python install).
Daniel (another one).
···
On 26 May 2016, at 19:56, Daniel Dunbar via swift-dev <swift-dev@swift.org> wrote:
Can someone who can reproduce this issue please file a bug on bugs.swift.org with as much information as possible about what exactly is hanging?