我为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.转移等待几分钟.不久之后,他们的查找器应弹出一个窗口,显示一个名为sysdiagnose_timestamp_.tar.gz的文件.请他们邮寄给你.我的大概是5 MB.关于sysdiagnose man page的更多细节.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
