I want to share some feedback following my latest bug: an unexplained crash which no symbolication could help resolve.
Given the following property of my City object:
in City.h
@property (nonatomic, retain) NSString * name;
The destructor looked like this in City.m
- (void) dealloc { [super dealloc]; [name release]; }
This code had worked perfectly fine on every iOS platform for years, until I compiled for the first time for t the arm64 architecture. Then it stopped to work, with an EXC_BAD_ACCESS (SIGSEGV) of subtype: KERN_INVALID_ADDRESS.
Not having, initially, an iPhone 5s at hand to find where the problem was exactly, I could only rely on the crashlogs and the symbolication for arm64. Unforunately, they would not indicate anything useful.
(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 520 _CFAutoreleasePoolPop + 24 -[NSAutoreleasePool release] + 148
Well, it did talk about some release pool problem, but could never pinpoint the above section of code.
It was not until I was able to use a friend’s iPhone 5s terminal, that I finally realized that the destructor should actually read like this:
- (void) dealloc { [name release]; name = nil; [super dealloc]; }
Calling the super prior to releasing and erase the name pointer would cause a crash on the A7 chip in a 64-bit slice.
Of course, you surely have been using ARC for a long time already, and won’t care too much about this old-stlye kind of problems. But I am not fond of managed memory, no matter the platform. I will continue to use manual memory allocation/de- as long as the language offers to do so.
Oh, and, if anyone is interested in the arm64 debug symbols for Xcode, I keep them at hand for download. Just ask me with the form below. Apple won’t like it, but I don’t like them either, so we’re even.
Many thanks to @dsultan for his precious help & time.
! Shana Tova שנה טובה !
Gabriel