In previous versions of instruments, there was a little 'i' button in the allocations tool which allowed you to do things like enable 'track allocations', which allowed you to get object counts of referrers who had currently or historically either retained or released the object - I think even for ARC. I'm currently using 6.3 and I cannot find this functionality at all. Has this been removed from the instrument?
Apple moved the instrument configuration information you would access with the Info button to the lower right area of the trace document window in Xcode 6.
Related
I am facing app freezing issue that is not getting detected in exception breakpoints. All my UI related code runs on main thread. As suggested in the question My app freezes but no error appears, I tapped on the pause button to check error, but cannot figure out anything from it. Please help me understand better. Attaching the screenshot of my xcode screen here:
When your app freeze.. try the following and resolve it
In Xcode(8 or Higher)
Analyze Code - Command+Shift+B
Enable Address Sanitizier in Xcode
Memory Graph
Thread Sanitizer and Static Analysis
Xcode makes it easier to find several new categories of bugs with improvements in Runtime Sanitization and the Clang Static Analyzer. The Thread Sanitizer will help you find data races and other concurrency bugs. The static analyzer has been extended to search for localizability issues, check nullability, and find memory leaks in MRR code.
Edit Scheme – Diagnostics tab
“Enable Thread Sanitizer” checkbox
Build and Run
View all of the generated runtime issues
Can choose to break on every issue
Since my latest update to the Instruments 6.1 I can't find "Show Obj-C only" checkbox anymore. Does somebody know if it has been removed completely or where one can find it?
Please, see attached images.
old Instruments checkBoxes:
new Instruments checkBoxes:
Looking through the Instruments User Guide by Apple you stumble upon many screenshots of the UI. All of them are missing the "show obj-c only" section. They definitely removed the feature from instruments.
One of the reasons may be that according to the Xcode release notes instruments supports swift (Instruments supports Swift, displaying Swift symbols in stack traces) and therefore they would have to either change the title of the feature or add a similar feature for swift. They apparently choose to remove it entirely since almost all of its functionality can be achieved by using the "Hide System Libraries" option and "Data Mining" section.
#Aaron Brager asked about the topic in the apple developer forum as well and received pretty much the same answer.
=> Apple felt like its functionality was redundant and it could/should be removed! Therefore they acted accordingly.
P.S.: as the answerer in the dev forum asks: if you have a use case that got more difficult, feel free to file a bug report.
I've also noticed this and while it's not exactly the same, I use the following toggle in the new interface builder to focus on my personal code:
Toggle Off:
Toggle On:
I have a huge synchronization process in which I download and unzip 400-500 XML files and then parse it. With this data Im going to create a lot of core data objects over the RestKit API. At the beginning, I had a memory warning with live bytes of 450mb+ because I did not using autorelease pools and only tried to save core data on the end.
I fixed that, saving now frequently to core data and using #autoreleasepool blocks. When im running my app now with instruments, I can see how the live bytes only being 20mb-30mb, always releasing memory and never going to size up. The process just works. But when I start the app without instruments, after a view files I get a Memory Warning. Later on the app crashs.
What is the differene between running the app with and without the instruments tool? Why does it end in different results?
I'm adding this answer because I'm so happy that I came across this page.
What #borrrden suggested is partially true. You can configure which Build settings it will use when you profile. To configure this, goto Xcode and open the Edit Scheme dialog and select in the left menu Profile XXX.app. You will see you can choose a Build Configuration (either Debug or Release).
What #hooleyhoop commented was more crucial to find the solution. Even if your Profile Build Configuration is set to Debug, there is still a difference between Profiling and a default Run from within Xcode. You can specify Diagnostics in the Run section. Right there, there is an option called Enable Zombie Objects under Memory Management. Make sure that this option is unchecked.
These diagnostic Run settings are not used while profiling. That is the explanation for the behavior you are experiencing. There isn't a Diagnostics tab on the Profile section as well.
The result is that my game (Gump) crashed after 5 minutes of doing nothing in the main menu with Zombie Objects enabled. Once I disabled Zombie Objects, my game runs as far as I know for an infinite amount of time. After 45 minutes, still no Memory Warnings.
According to ASLR(Address Space Layout Randomization), It provides random stack and heap allocations and page load every time a process starts, and randomize the address where objects are placed in virtual space of a given process.
But in my application running on ios, i create an object named ObjectA, after several reload the process ,i found that the address of ObjectA is all the same ,no randomize.
How does Apples's own ASLR implementation work? Why ObjectA's address is all the same?
What you mean for "several reload"? You should explicitly quit the application, because of the multitasking you might reopen the same process.
eg.
This is one of my applications printing out the address of a UIViewController instance, as you can see the address of the object is different in every execution.
First run: <DCViewController: 0x13d4a0>
Second run: <DCViewController: 0x2880f0>
Third run: <DCViewController: 0x2a2050>
(I do not think this is the case but in XCode there's an option to enable PIE (Position Independent Executable) under "Build Settings" and it's called "Don't Create Position Indipendent Executables", you can find it easily but typing "pie" in the search box. This option should be set to No).
EDIT:
Moreover Xcode will only make PIE binaries if deployment target is >= 4.3
Hope this helps =)
For completeness, the guy who did the work to answer that question was Dino Zovi in Apple iOS 4 Security Evaluation. My apologies if someone else published before Dino (I am not aware of the work or who you are).
Zovi published his stuff well before Apple published iOS Security. Dino's work is still more complete.
Summary: Can you add to my checklist of things to watch out for when migrating to iOS 5? StackOverflow has been invaluable as I've worked on upgrading to iOS 5. I've discovered some pretty basic things I'd missed prior to Xcode 4.2, and I'm wondering what other "gotchas" might be lurking.
Detail: With iOS 5 shipping this week, I've had to make some changes to a couple of my apps. Xcode 4.2 does a much better job analyzing memory management code because of the new ARC feature. The iOS 5 update is a great point at which to review all your memory management code. The new compiler also finds a number of other issues that earlier compilers missed. Kudos to the Apple compiler engineers. Here are the main things that have helped (and many of them will also apply to earlier versions of iOS).
Make sure to call [super dealloc] at the END of your dealloc methods, not the beginning.
In viewDidUnload, some people have reported bugs that require [super viewDidUnload] to be called at the end, not the beginning, of your viewDidUnload.
Understand retain counts, synthesized setters, and when to call release or autorelease. The new compiler will point out more problems than the older compilers did. (I thought I'd been careful, but apparently I wasn't careful enough.) Apple's memory management guide is required reading -- no shortcuts.
It's a good idea to turn on zombies when debugging (in Xcode, choose Product | Edit Scheme... and select the Debug scheme; on the Diagnostics tab, check Enable Zombie Objects). This can help you find attempted uses of zombies (objects you shouldn't be using any more).
The Leaks instrument is also helpful. Run your app in Profile mode and choose the Leaks template. In the Instruments window, select the Leaks instrument and check the box that says "Gather Leaked Memory Contents" and it will help you see where the leaked memory originates in your code.
There are a few odds and ends I've encountered:
Apple's singleton pattern needs "oneway" added to the return type declaration:
- (oneway void) release { }
You may need to manually add "armv6" as an architecture type in your Build Settings (and be sure Build Active Architecture Only is set to NO).
Any other suggestions of potential pitfalls I should look for? I have a feeling that my apps are more stable now, but I felt pretty good about them before.
1/ Modal controllers behave differently, if you were changing their size. If you need modal dialog of a different size, consider using iOS 5 child view controllers.
2/ For a table, if you were returning nil section header and positive height, in iOS 4, the header was hidden. In iOS 5, you have to return zero height for nil headers.
3/ UDID is deprecated. You can use CFUUIDCreate to create a unique id and save it into your settings but be aware that a device data can be backed up and then restored to another device, leaving you with two devices with the same id. I solved the situation by saving my id into keychain with attribute kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
About your list:
[super viewDidUnload] should be always called as the last statement in your viewDidUnload. The logic is the same as in [super dealloc]. Note, that you should also call [self viewDidUnload] in your dealloc (if you don't already release your memory there) because it is not called implicitly (although sometimes it is).
From my experiments, leak detection in Instruments don't report leaks on properties which are synthesized without assigning a property name.