5
votes

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

1
without seeing your code, it's not possible to conclude anything with 100% certainty.Mitch Wheat
what specifically would you like to see in the code?amehta

1 Answers

0
votes

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.