我为StandardOutput / StandardError尝试了很多不同的NSPipe / NSfileHandle组合,以确保问题与填充这些缓冲区无关.示例1和2.我的猜测是它没有相关性,因为它在很多系统上工作正常,并且_dyld_start在应用程序生命周期中为时过早,无法填充StandardOutput / StandardError.
关于这个问题的其他说明:
>从终端启动帮助应用程序工作正常.
>在卡住的进程上附加和分离gdb并且值得工作正常并且在完成后NSTask在-waitUntilExit之后接收工作.
>使用fork(2)和execv(3)而不是NSTask能够启动并运行帮助程序.
>父进程是沙盒,但我认为之前的报告在Mac OS X 10.6 / 10.7上进行了非沙盒处理.
活动监视器中的过程示例的屏幕截图:
任何线索或调试技巧,以确定帮助器卡在_dyld_start中的原因是受欢迎的!
解决方法 既然没有人回答,我会抛出一些想法.也许其中一个是答案 – 只是猜测 – 但是由于线索和提示是受欢迎的,你可以看看:>崩溃转储中已加载库的列表(可能有线索)
>在子进程中发生的任何错误(在fork之后).但是,我明白为什么回到任何post-fork错误都很困难.
如果我没记错的话,NSTask调用posix_spawn(2).这可能是一个线索,因为使用fork(2)和execv(3)似乎工作,你可以专注于NSTask和非阻塞替代之间的差异.很明显,一开始就发生了一些阻止孩子正常执行的事情.
>你确定它被卡住而没有崩溃吗?就用户所知,你的应用程序你的应用程序看起来不会崩溃.只有子进程会崩溃.
>作为最后的手段,你可以尝试寻找发生的任何马赫异常(如果
任何,这将意味着一个错误,你将无法做到
无论如何要恢复.但它仍将提供有价值的线索).
>您可以告诉愿意的定制者向您发送他们的sysdiagnose.为了达到这个目标,请他们点击Command Option Control.转移等待几分钟.不久之后,他们的查找器应d出一个窗口,显示一个名为sysdiagnose_timestamp_.tar.gz的文件.请他们邮寄给你.我的大概是5 MB.关于sysdiagnose man page的更多细节.
以上是内存溢出为你收集整理的objective-c – NSTask子进程卡在_dyld_start中全部内容,希望文章能够帮你解决objective-c – NSTask子进程卡在_dyld_start中所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)