为什么归档时xcode 4.3.2挂起? [英] Why does xcode 4.3.2 hang when archiving?
问题描述
当我尝试存档构建文件时，xcode挂在多彩的死亡死机上.它曾经可以正常工作，但是除非我手动删除存档文件，否则我将无法再浏览存档.我可以将设备构建成没有问题的设备.我手动删除了档案中的所有内容(通过删除实际的档案文件)，并且档案/组织器窗格显示正常，因为其中没有任何内容(因为我删除了档案).但是，当我尝试再次存档时，它会生成，然后尝试再次打开存档/组织器窗口，然后挂起.它确实产生的存档文件大约是30兆存档文件...但是我怕使用它..
When I attempt to archive a build, xcode hangs with the colorful spinny wheel of death. It used to work fine, but I can no longer browse the archive anymore unless I delete the archive files manually. I can build to a device fine without problems though. I deleted all content from the archives manually (by deleting the actual archive files) and the archive/organizer pane shows fine, because nothing is in it (because I deleted the archives). But when I attempt to archive again, it builds, then attempts to open the archive/organizer window again, and it hangs. The archive file it does produce though is about a 30 meg archive file... But I'm afraid to use it..
当死亡的棘轮旋转时，打开活动监视器"将显示以下内容: "xcodebuild"具有约80％的CPU使用率 "opendirectoryed"具有约30％的CPU使用率.
While the spinny wheel of death is spinning, opening "Activity Monitor" shows the following: "xcodebuild" has about 80% CPU usage "opendirectoryd" has about 30% CPU usage.
我已经在Lion上卸载并重新安装了XCode 4.3.2，没有任何结果.
I have uninstalled and reinstalled XCode 4.3.2 on Lion with no results.
我也在从Unity3D构建项目.
I'm also building projects from Unity3D..
有人在不同的线程中提到了以下内容:我遇到了类似的问题，我发现做的符号链接是导致从/Developer/usr/bin到/usr/bin的问题的原因(因为Xcode 4.3将某些高管)"
Someone mentioned the following in a different thread: "I had similar problems I found that a symbolic link I did was the cause of the problem from /Developer/usr/bin to /usr/bin (because Xcode 4.3 moved some of the execs)"
我什么都没发生.将所有类都移到新的项目"中并没有帮助，因为每次我从Unity内部构建项目时，项目都是全新创建的.
I have nothing like this going on. And moving all of the classes to a new "project" doesn't help because the project is created brand new each time when I build from within Unity.
XCode 4.3.2 Mac OS X(10.7.3)
XCode 4.3.2 Mac OS X (10.7.3)
任何想法或建议对我都会很有帮助.什么都没有. 谢谢.
Any ideas or suggestions would be very helpful to me. Anything at all. Thanks.
推荐答案
快速解决方案:执行以下命令:xcode-select -switch/Applications/Xcode.app/Contents/Developer/
Quick Solution: execute the following: xcode-select -switch /Applications/Xcode.app/Contents/Developer/
我如何解决的:
打开打开目录的调试日志记录:"odutil set log debug"
Turned on opendirectoryd debug logging: "odutil set log debug"
在/var/logs/opendirectoryd.log文件中进行搜索.
Searched around inside the /var/logs/opendirectoryd.log files.
我不断看到这遍又一遍的垃圾邮件:
I kept seeing this block of logs spammed over and over again:
2012-04-12 11:29:28.420 CDT-31053.1185984，模块:SystemCache-用于更多工作的信号灯
2012-04-12 11:29:28.420 CDT - 31053.1185984, Module: SystemCache - Signaling semaphores for more work
2012-04-12 11:29:28.420 CDT-31053.1185984，模块:SystemCache-最终确定响应对象0x7fae5b21acb0，请求已完成
2012-04-12 11:29:28.420 CDT - 31053.1185984, Module: SystemCache - Finalizing response object 0x7fae5b21acb0, request is complete
2012-04-12 11:29:28.420 CDT-31053-客户端:"xcodebuild"，退出时出现0个会话，0个节点和0个活动请求
2012-04-12 11:29:28.420 CDT - 31053 - Client: 'xcodebuild', exited with 0 session(s), 0 node(s) and 0 active request(s)
2012-04-12 11:29:28.421 CDT-触发器-新节点触发器正在监视'opendirectoryd:nodes;(register | unregister);.*'
2012-04-12 11:29:28.421 CDT - Trigger - new node trigger watching for 'opendirectoryd:nodes;(register|unregister);.*'
2012-04-12 11:29:28.421 CDT-semaphore_wait将等待-最大数量的成员资格通话已在进行中
2012-04-12 11:29:28.421 CDT - semaphore_wait will wait - maximum number of membership calls are already in flight
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-客户端:xcodebuild，UID:501，EUID:501，GID:20，EGID:20
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Client: xcodebuild, UID: 501, EUID: 501, GID: 20, EGID: 20
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-添加到全局请求列表-新计数1
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Adding to global request list - new count 1
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-mbr_identifier_to_uuid请求，UID:501
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - mbr_identifier_to_uuid request, UID: 501
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-semaphore_wait将等待-max_active_work
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - semaphore_wait will wait - max_active_work
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-semaphore_wait将等待-workq
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - semaphore_wait will wait - workq
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-提交至管道
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Submitting to pipeline
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-执行请求管道
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - executing request pipeline
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-缓存命中-dev14(0x59574CC0)
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Cache hit - dev14 (0x59574CC0)
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-提交至响应管道
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Submitting to response pipeline
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-执行响应管道-0x10ba2f670
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - executing response pipeline - 0x10ba2f670
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-mbr_identifier_to_uuid已完成，已交付1个结果
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - mbr_identifier_to_uuid completed, delivered 1 result
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-从全局请求列表中删除
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Removing from global request list
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-用于更多工作的信号灯
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Signaling semaphores for more work
2012-04-12 11:29:28.421 CDT-31053.1185985，模块:SystemCache-最终确定响应对象0x10ba2f670，请求已完成
2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Finalizing response object 0x10ba2f670, request is complete
2012-04-12 11:29:28.421 CDT-31053-客户端:"xcodebuild"，退出时出现0个会话，0个节点和0个活动请求
2012-04-12 11:29:28.421 CDT - 31053 - Client: 'xcodebuild', exited with 0 session(s), 0 node(s) and 0 active request(s)
2012-04-12 11:29:28.422 CDT-触发器-新节点触发器正在监视'opendirectoryd:nodes;(register | unregister);.*'
2012-04-12 11:29:28.422 CDT - Trigger - new node trigger watching for 'opendirectoryd:nodes;(register|unregister);.*'
2012-04-12 11:29:28.422 CDT-semaphore_wait将等待-会员通话已在飞行中
2012-04-12 11:29:28.422 CDT - semaphore_wait will wait - maximum number of membership calls are already in flight
2012-04-12 11:29:28.422 CDT-31053.1185986，模块:SystemCache-客户端:xcodebuild，UID:501，EUID:501，GID:20，EGID:20
2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - Client: xcodebuild, UID: 501, EUID: 501, GID: 20, EGID: 20
2012-04-12 11:29:28.422 CDT-31053.1185986，模块:SystemCache-添加到全局请求列表-新计数1
2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - Adding to global request list - new count 1
2012-04-12 11:29:28.422 CDT-31053.1185986，模块:SystemCache-mbr_identifier_to_uuid请求，UID:501
2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - mbr_identifier_to_uuid request, UID: 501
2012-04-12 11:29:28.422 CDT-31053.1185986，模块:SystemCache-semaphore_wait将等待-max_active_work
2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - semaphore_wait will wait - max_active_work
2012-04-12 11:29:28.422 CDT-31053.1185986，模块:SystemCache-semaphore_wait将等待-workq
2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - semaphore_wait will wait - workq
我在google中搜索了这些字符串之一，并提出了隐藏在苹果开发者论坛中的以下解决方案:
I searched for one of these strings in google and came up with the following solution hidden away on apple's developer forum:
"似乎旧的xcodebuild命令被新的Xcode安装程序留下了.执行"xcode-select -switch/Applications/Xcode.app/Contents/Developer/"和"make clean"项目后，完美."
"It seems that the old xcodebuild command was left lying around by the new Xcode installer. After executing 'xcode-select -switch /Applications/Xcode.app/Contents/Developer/' and a 'make clean' the project built perfectly."
实际上，它现在可以工作.一定是一些不正确的怪异符号链接.许多其他人似乎在opendirectoryed上遇到问题，并且符号链接断开导致大量CPU高峰.
Indeed, it works now. Must have been some weird symbolic link that wasn't correct. Lots of other people seem to have issues with opendirectoryd and a broken sym link causing a large CPU spike.
这篇关于为什么归档时xcode 4.3.2挂起?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
