Zombie: Archiving Failed using Integration Menu - ios

When I tried to archiving the project directly using Xcode menu (Product - Archive), it works well. But when I tried to execute it from the Integration menu (bot), I got this error:
Build operation failed without specifying any errors. Individual build
tasks may have failed for unknown reasons. One possible cause is if
there are too many (possibly zombie) processes; in this case,
rebooting may fix the problem. Some individual build task failures (up
to 12) may be listed below.
What happen? I couldn't find any error messages and completely have no clue on what's going on. I have tried to reboot the macmini and also revert the changes but it still.

UPDATE (Edit 3)
The issue has been fixed on Xcode 11, from beta 3:
Xcode uses response files by default to pass input files to the Swift compiler. To turn this behavior off, set USE_SWIFT_RESPONSE_FILE to NO.
You can use an unlimited number of Swift files in a target. (35879960)
Old answer
I've only seen this error arising when the total of files (notice all their respective absolute paths count) exceed the command line length limit (looks like it's imposed by the OS, currently 262144 bytes on my rMBP). It's a known issue.
To fix this (AFAIK), you have 2 options:
Fast (short term): Put your project on a shorter path on the server (like moving the project from /Users/mrjimoy_05_server/myprojects/mycoolproject/ to /p/mycoolproject)
Better (long term): While the first solution might work, for now, you'll probably reach the same point where you're now in the near future. So a better solution is to modularize your app (separate it into frameworks/projects). Since every module will get built separately, it'll be much harder to reach the limit and get this error again.
I hope it helps.
PD: Looks like the error thrown by the New Build System is:
unable to spawn process (File exists)
Edit 1
The error thrown by the New Build System on Xcode 10 now is:
unable to spawn process (Argument list too long)
Edit 2
The Swift team have solved this issue, but it also needs some work from the Xcode team, which hasn't been done yet on the latest released Xcode version (10.2)

Related

Transferring Xcode Project from one computer to another brings random errors?

I have a Xcode project I got from another developer. Initially when I opened it it has a bunch of errors (most of which were un-updated frameworks). I got it to work after a while and I fixed it. I want pass it back to the manager since I'm leaving uni in a few months. I copied it over to my friends Mac to see what would happen if I just took the project and all it's folders and made it a zipfile. It didn't work for some reason. It gave me an error:
error: using bridging headers with framework targets is unsupported
But why did that come up? I mean it's the same code on the slightly different versions of Xcode (13.1 versos 14.1) but I doubt there was a massive change between the two that would cause this. I want to be able to pass these app later in the future without having to care about this stuff. I made a GitHub (link below) would cloning that work? Also the laptop I chose was just a fresh reset. Would it be due to not having coco-pods installed?
I feel like I could go through and fix it all on that laptop and document that but then I'm afraid that every time I put it on a new one it would come up with random errors every single time making my documentation moot.
https://github.com/AbdullahMSaid/SonicExperiment-Works
With big help this was Fixed.
Things that fixed it.
Having the correct version of Xcode
Turning everything from absolute path to relative
Lots of other code fixes. But those are my project specific.
You don't need bridging headers in framework. Use should have something like "YourFramework.h" where you can import your .h files.

Xcode 8.3 Indexing & Building Extremely Slow

I am posting this after reading many similar posts on here regarding this issue and none of the solutions that worked for other people not working...
Xcode Version 8.3.3 (8E3004b)
Swift 3.1
Things I tried
Deleting Derived Data folder
Deleting Workspace File
Cleaning Build Folder
Cleaning Build
Reinstalled Xcode (after complete removal)
I also looked for Swift Issues:
Removed all concatenating strings
Cleaned up Swift arrays and dictionaries
Added Whole module optimizations
This all started happening after last Xcode update of 8.3.3. My project was compiling within seconds and now I have to wait at least 15 mins for it to index, then 5 minutes to compile after everything I change even something small in code.
When Building, it get stuck in "Compiling Swift source files". Is there way for me to look in to where it is actually getting stuck?
BIG UPDATE
I tried pretty much everything. Read every article, post, ect. NOTHING worked. My project was created right after 10.0.
Solution
Creating a new project and copying each file worked! It used to take 8-9 minuted to build. Now less than 2 seconds!
Apple knows about this problem, and says that Xcode 9 beta will perform much better. Note that if you don't want to update to Swift 4, you can continue compiling in Swift 3 mode using Xcode 9. The big limitation is that you won't be able to submit your project to the App Store until Xcode 9 goes final.
Also, Xcode 9 contains a new build system. You don't get it by default: you have to turn it on for this project. Choose File > Project Settings and switch the pop-up menu to New Build System (Preview). This is experimental, but it will be the default build system eventually, so it would be interesting to know whether this makes an appreciable difference.
If you don't want to update to Xcode 9 beta, you will just have to do a binary search: comment out all your code and start adding it back, piece by piece, until you find that piece that's causing the trouble.
The best way to work this out is to find what out what the build is doing while compiling your code. This is a really useful tool to use: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode
When you run this tool it will show you what methods are taking the longest to compile, and then you fix those. Once you have done that, you can also try the answer I gave here to decrease the build times: Extremely long compilation times with Swift in Xcode

Xcode export localization throws error "Argument list too long"

I've got a very curious error to share regarding Xcode localization process. I will try to share as much detail as legally possible.
From Xcode, I am trying to export an XLIFF file to send to our translators, via "Editor > Export for Localizations". However, this immediately throws error with the message:
The operation couldn't be completed. Argument list too long
This is indeed confusing, as I cannot find a more verbose log anywhere (I have already tried checking my Console.app). So, I spent quite a few time googling – to no avail. I couldn't find similar case like this. The error itself happens only when I am trying to export for localization. I can build and run the app just fine.
Facts
~ $ xcodebuild -version
Xcode 8.2
Build version 8C38
~ $ xcode-select -version
xcode-select version 2347.
~ $ echo $PATH
/Users/david.christiandy/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/david.christiandy/arctools/arcanist/bin:/usr/local/go/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
I am using Xcode 8.2 on macOS Sierra 10.12.5.
The error happens only when I try exporting from localization. This is also true when I run the localization process via xcodebuild -exportLocalizations.
I can build and run the app just fine. (I believe) there's no problem with my header search paths.
Attempts
Thought there was something wrong in the code, so I tried to run the export process (via xcodebuild command) in a CI. Somehow, it's working. For the record, I am using Bitrise CI with the same stack as my system (Xcode 8.2.x, macOS 10.12)
Asked colleagues to run export process on their machines, and they have the same error.
This leads me to think that there must be something wrong with the configuration. So I made a standalone project to confirm that the export process fails consistently. Turns out, it works just fine!
So, the hypothesis I got currently is:
There's probably something wrong in the code, and
There might be tools/software (that most of our iOS engineers installed) that might contribute to the error (since the CI completes just fine).
I don't know why the CI can run the export process just fine, and I don't know when it might suddenly stop functioning (just like our local machines).
Appreciate any help on this matter. Thank you!
I also asked this question on Apple developer forums, here is the link: https://forums.developer.apple.com/thread/86762
“Argument list too long” sounds like E2BIG, which you get when you try to run a child process with a huge argument list (I believe the current limit is 256 KiB). I suspect that Export for Localizations is running some sort of command line tool to do that work (probably the extractLocStrings tool, which you’ll find lurking within Xcode’s app bundle) and passing it full paths to each of the files in your project. Depending on how many files you have and how long those paths are, it’s easy to run into problems like this.
One of the ‘fun’ things about bugs like this is that they are dependent on where you place your project. Things might work if the project is at the top of your home directory but fail if it’s nested deep inside a subdirectory.
That also suggests a potential workaround, namely, to move your project further up in the directory hierarchy.
Finally, you should definitely file a bug about this. I believe we’ve seen this before (r. 30703294) but your report will help reinforce that this is causing problems for developers in the field. Please post your bug number, just for the record.
Several days ago before I read this answer, I managed to get the export working by deleting some folders via Xcode (remove references only). Initially I suspected that there's an invalid format within the folders that I deleted, but when I tried deleting other folders, the export process works just fine.
I also tried exporting strings using Xcode 9, and I didn't encounter the problem. So hopefully this bug is only for Xcode 8.3.3 and below.

Swift - Command failed due to signal: Segmentation fault: 11 when build in configuration Release

I'm trying to compile a project then the Xcode said that.
I hope to receive the answers for these concerns, here are the situation:
Xcode 8.3.2
Swift 3.0
All Frameworks are built via Carthage (Exclude Fabric & Crashlitics)
When I build in Debug configuration everything are ok, but when I change to configuration Release then the compile always failed.
I tried to change the Optimization Level to Fast, Single-File Optimization[-O] then the Xcode works well and I also can archive to ipa file.
I have some concerns, could you please review ?
+ How do I completely resolve this problem and keep the default Optimization Level value for configuration Release ?
+ If I change Optimization Level value to Fast, Single-File Optimization[-O], could I submit the binary file to App store review ? Does it violet Apple's tos ?
Thank you,
you can get this error when the compiler gets too confused about what's going on in your code. I noticed you have a number of what appear to be functions nested within functions. You might try commenting out some of that at a time to see if the error goes away. That way you can zero in on the problem area. You can't use breakpoints because it's a compile time error, not a run time error.
And it might be possible that you have used a custom frameworks so just remove that custom framework which shows error

Xcode Won't Parse Files to Find Errors

I have a strange issue that I haven't seen or read about anywhere else. My Xcode no longer parses all of my files to find issues/errors. It will display any issues or errors in a file I am currently viewing, and these will persist thereafter, but with 400+ files I can't reasonably visit each one to make it compile. Xcode can build successfully if the code is valid, however I can never know when that is, since I see no errors. Indexing occurs, but no compiling takes place.
Also, when building, the status bar states that Xcode is compiling x out of however many total compile sources but the total number is usually not even close to the actual total number. For example it may say compiling x out of 40 files when there are actually 400 compile sources.
I wasn't doing anything out of the ordinary from my usual tasks when this issue began. New projects will compile, then randomly stop compiling after a period of time.
Things I have tried:
nuking derived data
quitting Xcode/restarting computer
Recloning the project from a known working repository. It will build but won't find errors/issues when they do exist. There should be at least a handful of minor issues but none appear.
Reinstalling Xcode (4.5.2)
tried both GCC 4.2 and LLVM 4.1 compilers
Has anyone experienced this issue before and found a solution? This problem has made my job extremely difficult and any help would be much appreciated.
It does sound like corruption of DerivedData. Try this:
Clean your target: cmd+shift+K or Product->Clean
Quit xcode
Delete the contents of /Users/your_user/Library/Developer/Xcode/DerivedData
Restart xcode
(It's safe to delete this folder's contents. But if you're nervous about that, back it up first).
You should be good to go.

Resources