节目接收信号:"0".没有先兆的麻烦 [英] Program received signal: "0". No prior sign of trouble

问题描述

在系留(至Xcode 3)的iPod Touch上运行长时间运行的声音处理应用程序.现在两次，第一次经过1小时40分钟，第二次经过2小时20分钟后，该应用程序以信号0结束.这里和其他论坛上对信号0进行了多次讨论，似乎都怪罪于内存不足

Running a long-running sound processing app on tethered (to Xcode 3) iPod Touch. Twice now, after 1 hour 40 minutes the first time and 2 hours 20 minutes the second, the app has ended with signal 0. There are multiple discussions of signal 0 here and on other forums, and they all seem to blame running out of memory.

但是我会不定期地转储使用的内存，在上一次测试中，它从运行初期到结束前仅增长了约3.3mb.而且我在应用程序委托中有一个钩子可以记录是否收到内存警告(在模拟器上对其进行了测试)，并且该警告没有被触发.

But I dump the memory used at intervals, and, on the last test, it grew only about 3.3mb from early in the run until just before the end. And I have a hook in my app delegate to log if I get a memory warning (tested it on the simulator) and it did not get triggered.

简而言之，没有暗示内存不足的情况.

In short, there's no suggestion of an out-of-memory condition.

在这两种情况下，应用程序都在程序中写入文件并传输到服务器的位置结束. (这种情况每20分钟发生一次.)正在传输的文件相对较小(在故障点传输的文件为86kb).根据日志，似乎在读取文件以进行传输时可能已发生故障.这将涉及创建包含要传输的数据的NSString. (也许这里的逻辑可能更简洁一些-它使用的是NSString stringByAppendingFormat，我承认，这是值得怀疑的.)

In both cases the application was ended at a point in the program where files are written and transmitted to a server. (This occurs every 20 minutes.) The files being transmitted are relatively small (86kb for the one being transmitted at the point of failure). Based on the logs, it appears that the failure may have occurred while reading the file to prepare for transmission. This would have involved creating an NSString containing the data to transmit. (Probably the logic here could be a little cleaner -- it's using NSString stringByAppendingFormat, which is, I'll admit, suspect.)

关于如何调试此问题的任何建议?它会响吗?我可以在没有任何警告的情况下离开存储空间吗?手机上是否有可能入睡"的东西?您可以在Xcode 3上进行拴系测试的时间有简单的限制吗?

Any suggestions on how to debug this? Does it ring a bell? Could I be getting out of storage without any warning? Is there something that could be "going to sleep" on the phone? Is there simply some limit to how long you can run a tethered test on Xcode 3?

推荐答案

我不确定这是否是最终答案，但最近两天我已经整理"了代码，并解决了一些与存储相关的问题.修复了一些小漏洞(泄漏"是无价之宝，但接口有点像辅助接口)，但更重要的是，我在代码中固定了一个位置(在我的原始帖子中被保留了)，很可能在一个位置分配了100mb左右的空间.方法.存储已全部自动释放，但这仍然意味着它在分配曲线中造成了很大的波动. (这一切发生的位置与崩溃发生的位置非常接近.)

I'm not sure this is the final answer, but I've "massaged" the code for the last couple of days and fixed several storage-related problems. Several small leaks were fixed ("Leaks" is an invaluable took, but the interface kinda sux), but, more importantly, I fixed one place in the code (alluded to in my original post) that was likely allocating 100mb or so in one method. The storage was all autoreleased, but that still meant it created a substantial hump in the allocation curve. (And where this all happened corresponded pretty closely to where the crash occurred.)

修复这些问题后，该应用程序运行了3个多小时-尚未准备好宣布胜利，但看起来不错.

After these fixes the app ran for over 3 hours -- not quite ready to declare victory, but it's looking good.

(丑陋的代码(不是我的！)反复使用stringByAppendingFormat来建立相对较长的字符串以进行网络传输.如果您有N个长度为M的字符串连接在一起，并且反复使用stringByAppendingFormat结果大约是N * M，但是您要遍历大约N * N * M/2个存储来构建它.如果N在2000的数量级上，那将是一个很大的数字.累积直到池耗尽为止.使用NSMutableString的附加函数效率更高.)

(The ugly code (not mine!) was using stringByAppendingFormat repeatedly to build up a relatively long string for network transmission. If you have N strings of length M to concatenate together, and you use stringByAppendingFormat repeatedly to do it, the result is about N*M, but you spin through about N*N*M/2 storage to build it. If N is on the order of 2000 that gets to be a big number. And though it's all autoreleased it still accumulates until the pool is drained. Using the append functions of NSMutableString is much more efficient.)

这篇关于节目接收信号:"0".没有先兆的麻烦的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！