5

我使用NSTask来运行我的助手应用程序。在 99% 的一个我的客户系统上，这工作正常，但有两个回复我，让我知道它没有。其中一个很好，可以让我查看每个远程桌面的问题。

我为 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 中的原因！

4

1 回答 1

-1

由于没有人回答，我提出了一些想法。也许其中一个是答案——只是猜测——但由于欢迎提供线索和提示，你可以看看：

  • 崩溃转储中已加载库的列表（那里可能有线索）
  • 子进程中会发生的任何错误（在 fork 之后）。但是，我明白为什么很难恢复任何分叉后错误。

如果我没记错的话，NSTask 调用posix_spawn(2). 这可能是一个线索，因为使用fork(2)andexecv(3)似乎有效，您可以关注NSTask与非阻塞替代方案之间的差异。显然，一开始就发生了一些事情，阻止了孩子正确执行。

  • 你确定它是卡住而不是崩溃吗？据用户所知，您的应用程序看起来不会崩溃。只有子进程会崩溃。
  • 作为最后的手段，您可以尝试查找是否发生了任何马赫异常（如果有的话，那将意味着一个错误，您无论如何都无法恢复。但它仍然会提供有价值的线索）。
  • 您可以告诉愿意的客户向您发送他们的系统诊断。为了这个目标，请他们
    打Command++++Option等待Control几分钟。不久之后，他们的查找器应该会弹出一个窗口，显示一个名为：. 请让他们邮寄给您。我的大约 5 MB。有关sysdiagnose 手册页的更多详细信息。.Shiftsysdiagnose_timestamp_.tar.gz
于 2013-03-25T20:22:41.330 回答