与分配工具一起使用时应用程序崩溃
我发现我的应用程序在与分配工具一起使用时崩溃。查看设备日志时，我可以看出这是“内存不足”崩溃。我的应用程序进程以及我的应用程序使用的其他进程都被抛弃。设备日志如下：
MyAPP <09da004ccd82e7a2c54e0ea6ab4eab24> 1990 (jettisoned) (active)
MobilePhone <6d3241e15be58311a76700272febc6d4> 635 (jettisoned)
accessoryd <6a25188f645a24b167cda5e0a86d486a> 121 (jettisoned)
当应用程序在没有仪器的情况下运行时，我没有遇到任何崩溃，并且用户认为该应用程序性能良好。几天来我一直专注于解决这个问题（几乎所有我的代码都被注释以找到问题）。
我的问题是 - 与仪器结合使用时应用程序崩溃是否会给最终用户带来问题？或者这只会在调试内存问题时给我带来问题？
注 1：当我将应用程序与仪器一起使用时，我根本没有与该应用程序进行交互。它加载视图控制器，进行异步服务调用，该调用返回结果，然后将结果填充到两个表视图中。由于仍然需要对象，因此不需要释放太多内容。
注 2：这是应用程序崩溃时分配工具中的实时对象列表片段（按大小按降序排列）。正如你所看到的，MYAPP 并不是真正的主要罪犯（表面上）
Size(bytes) Responsible Library Responsible Caller
131072 UIKit -[UIView(Internal) _subclassImplementsDrawRect]
45056 CoreGraphics zone_malloc
16384 libCGFreetype.A.dylib ft_allocate
11264 Foundation NSPopAutoreleasePool
8192 libCGFreetype.A.dylib ft_allocate
8192 Foundation NSLogv
7680 libCGFreetype.A.dylib ft_allocate
7680 libCGFreetype.A.dylib ft_allocate
7680 CoreGraphics argb32_mark_constmask
5120 CoreGraphics CGDataProviderCreateWithCopyOfData
4608 libCGFreetype.A.dylib ft_allocate
4608 libCGFreetype.A.dylib ft_allocate
4608 libCGFreetype.A.dylib ft_allocate
4096 libSystem.B.dylib __stack_chk_fail
4096 QuartzCore CA::Transaction::create()
4096 Foundation NSPushAutoreleasePool
4096 MYAPP -[CJSONScanner scanNotQuoteCharactersIntoString:]
谢谢
I have seen that my app crashes when used with the Allocation Instrument. When looking at the device logs, I can tell that it is a 'Low memory' crash. My app process in addition to others used by my app were jettisoned. Here is how the device logs look:
MyAPP <09da004ccd82e7a2c54e0ea6ab4eab24> 1990 (jettisoned) (active)
MobilePhone <6d3241e15be58311a76700272febc6d4> 635 (jettisoned)
accessoryd <6a25188f645a24b167cda5e0a86d486a> 121 (jettisoned)
I do not encounter any crashes when the app is running without instruments and the app is perceived by users to be performant. I have been focussing on solving this problem for a couple days (pretty much all my code is commented to find the issue).
My question is - Could the app crashing when used in conjunction with instruments pose a problem to the end user? Or is this only going to cause me issues when debugging memory issues?
Note 1: I am not interacting with the app AT ALL when using it with instruments. It loads a view controller, makes a asynch service call which returns results that are then populated into two tableviews. Not a lot to deallocate as the objects are still required.
Note 2: Here is a snippet of LIVE object lists from the Allocations Instruments (sorted by size in desc order) when the app crashes. As you can see MYAPP is not really the main offender (seemingly)
Size(bytes) Responsible Library Responsible Caller
131072 UIKit -[UIView(Internal) _subclassImplementsDrawRect]
45056 CoreGraphics zone_malloc
16384 libCGFreetype.A.dylib ft_allocate
11264 Foundation NSPopAutoreleasePool
8192 libCGFreetype.A.dylib ft_allocate
8192 Foundation NSLogv
7680 libCGFreetype.A.dylib ft_allocate
7680 libCGFreetype.A.dylib ft_allocate
7680 CoreGraphics argb32_mark_constmask
5120 CoreGraphics CGDataProviderCreateWithCopyOfData
4608 libCGFreetype.A.dylib ft_allocate
4608 libCGFreetype.A.dylib ft_allocate
4608 libCGFreetype.A.dylib ft_allocate
4096 libSystem.B.dylib __stack_chk_fail
4096 QuartzCore CA::Transaction::create()
4096 Foundation NSPushAutoreleasePool
4096 MYAPP -[CJSONScanner scanNotQuoteCharactersIntoString:]
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我以前也遇到过类似的问题。原来我使用的是未初始化的内存。使用分配运行会更改导致崩溃的内存值。
I've had a similar problem before. It turned out I was using uninitialized memory. Running with Allocations changed the value of that memory which caused the crashing.