Ipad pro only issue: app suddenly has corrupted memory

Hi,


i'm wondering if anyone can help me with this issue.


We have an app which support ios 5.1.1 to 9.2, is 64 bit, objective-c without arc, and has no problems, until we hit the ipad pro (currently running the simulator since we do not have an actual device).

There i'm getting all kinds of bad acces exceptions (just on starting the app) . My current crash is on a name string which has been initialized and has not changed, which suddenly doesn't point to a proper value

Also in the same collection i'm seeing proper strings with correct values and i'm seeing things like a strings which should have a predefined name suddenly pointing to stuff like: "/System/Library/Frameworks/CoreTelephony.framework/CoreTelephony:CTRadioAccessTechnologyCDMAEVDORev0" and other unexplainable values.


I can only come to the conclusion that the memory or pointer is corrupt. Which is really weird since nothing changed code wise (also the app runs fine on other simulators)


has anybody else had this problem?

does anybody have a fix?


thanks

Answered by DTS Engineer in 88915022

Two things:

  • It’s easy for incorrect code to consistently work on one platform and fail on another. The classic example of this is NSDate, which is a tagged pointer on some platforms and an actual object on others. If your code over-releases an NSDate, it’ll work fine on the former but cause mysterious memory management errors on the latter.

  • This sort of thing can change from release to release of the OS, and vary by hardware platform.

So the argument My code worked before so it must be the OS’s fault isn’t valid. OTOH, that doesn’t mean it’s not an OS problem (-: The only way to be sure is to debug the problem to the point where you understand the reason for the failure.

If you’re seeing a string disappearing out from underneath a ‘retain’ property, you should look at the malloc history of that string to see who released it.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

more info:


the current error is when i acces a xml value through xmllib. the retain count seems to differ from call to call even though its a 2 line function.

in one case its 3 which is correct. in another its 1 which is incorrect:

bad:

3 nameof 1st catagory

1 nameof 2nd catagory


good:

3 nameof 1st catagory

3 nameof 2nd catagory


finding and assigning:

.name = [XmlHelper AttributeValue: segmentNode find:"name"];


the xml to NSString convert after having found the xmlnode:

[NSString stringWithCString:(const char*)attribNode->children->content encoding: NSUTF8StringEncoding];


just found out that this problem also occurs on ipad air/air2 with ios 9.1. air2 we have an actual device which did not have these problems before.

Your first step here should be to run your app with Zombies enabled to see if it flags anything.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yes i have a dealloced object, but no they are not caused by my code, else i would have crashes on all platforms/hardware configs.

Also i have 0 warnings when analysing related to memory issues.


our app has been zombie free for 3+ years now and has been running stable until ios9 hit and boom i have all kinds of deallocation errors only on 64 bit devices with ios 9 on the most simple of class variables (NSString) which have a retain specified.

@property (nonatomic, retain) NSString *name;


Also removing code optimalisations on compile does not work.

correction:


My code should not be the problem unless apple has changed how retain/release works in ios9 in no-arc projects


Also:

i'm working on coverting the app to ARC as an experiment which seems to not have the corrupted memory issues so far

but that still won't solved the problem and it's very iffy to release something like that.

Accepted Answer

Two things:

  • It’s easy for incorrect code to consistently work on one platform and fail on another. The classic example of this is NSDate, which is a tagged pointer on some platforms and an actual object on others. If your code over-releases an NSDate, it’ll work fine on the former but cause mysterious memory management errors on the latter.

  • This sort of thing can change from release to release of the OS, and vary by hardware platform.

So the argument My code worked before so it must be the OS’s fault isn’t valid. OTOH, that doesn’t mean it’s not an OS problem (-: The only way to be sure is to debug the problem to the point where you understand the reason for the failure.

If you’re seeing a string disappearing out from underneath a ‘retain’ property, you should look at the malloc history of that string to see who released it.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
Ipad pro only issue: app suddenly has corrupted memory
 
 
Q