I have a bit of a dilemma — no matter what I do, I cannot get Apple's Instruments.app to symbolicate any of the included instruments while I'm profiling on my devices (it works OK in the iOS Simulator).
I've tried just about everything I can think of, including:
Checking that I'm actually building a dSYM
Switching between Debug and Release build schemes
Making sure that the signing certificate being used in my Development cert
Adding and removing my Derived Data folder from Spotlight's Privacy list
Clean & Build before profiling
Removing the Derived Data folder before building and profiling
I'm not sure where to go from here — I had symbols for an hour or two earlier in the week, but I just can't get them to show up at all anymore. It would be great to figure out what the mystical incantation is to make Instruments always find my app's symbols.
In the File menu there is an option for Re-Symbolicate Document. Choosing this, you can find your binary in the list and use the Locate button to specify the location of the dSYM manually. There is also a checkbox here for using Spotlight to find the dSYM; it's possible it got deactivated if Spotlight was borked at some point but is now fixed.
It seems that you cannot do this while Instruments is actually instrumenting, but it does seem to keep the setting for the next time you hit Record. It does not, however, seem to remember the setting after you close Instruments.
Did you ensure you are signing the app with a development profile (as opposed to a distribution profile)?
Be aware that you are usually using release builds with instruments so make sure you didn't choose a distribution profile for your release configuration...
I've seen Instruments 4.2 fail to symbolicate several times with the correct dSYM file.
After saving and quit/restart Instruments, it will then symbolicate.
(Sometimes I'll capture a small sample and make sure it works before collecting large samples.)
Aside from xcode's tools, you can use atos: https://stackoverflow.com/a/4954949/312725
Be sure to take slide into account as well: https://stackoverflow.com/a/13576028/312725
(I'm adding this information to several related questions that are related to that, but aren't exactly duplicate questions. This is copy-pasted, it's a honest attempt to help someone who googled that question rather then spam.)
Related
I am rebuilding an App and at the same time paring it down of unnecessary code and it contains "required frameworks" that I think were left over from copying a previous app shell for building this app. How can I determine if a framework is actually needed. I thought I could just leave them off and build the app and then add them as required to let it build successfully but in the past that has not worked well to my surprise as I have built and tested a previous App without any additional frameworks added and the App built and ran just fine on simulators and actually devices only to find out at submission time I forgot to add the frameworks before submitting it.
I am trying to be proactive and only put in the ones I need. Some, like the MediaPlayer are definitely not needed and I can eliminate them already but some are harder to determine.
Curious if there was an easy way to figure this out.
I've been running into a problem with Apple Instruments (4.6, Xcode 4.6.2 on 10.8.3).
Normally when using the Time Profiler, I can look at my source and see the hotspots without any problems (same project).
This time I've been trying to use the "Counters" Template to sample my CPUs Performance Counter Events. It samples the events as it should and I also have the same time based profiling information as well, however when I try to step into my code to look at the hot spots, like I can do for the "Time Profiler", all I get is "Unavailable" where I used to have the source. No Assembly either.
The Project is built as:
Release build
Debugging information is on and not stripped
DWARF + dsym is used to store the profiling data.
As I said, its the same configuration that works for the time profiler.
I already tried to (pretty much all that's stated in here: Xcode 4 Instruments doesn't show source lines , except for doing -O0, debug performance is not of interest to me)
recompile
relocate the dysm file using "File -> Re-Symbolicate"
As soon as I plainly close Instruments, start another Profile from Xcode and choose the Time Profiler, it works, if I go back to the Performance Counters, it stops.
Is this the default behaviour? Should it be like this? Has anybody already managed to get it working, in the current Instruments version? Otherwise it might be worth to file a bug with Apple.
Thanks a lot!
Try the Xcode 5.1 beta4. For me its fixed there: Counter works now.
The seed notes mentions some details what they did. Don't know if its under NDA.
I'm not really sure if this question is answerable as I am completely puzzled by this. Maybe if someone had a similar issue and can maybe point something out?
So I used 4 different CCParticleSystem effects in my app which run perfectly fine when built and installed from xcode. However, when I build and upload for testflight and download to my device, one of the CCParticleSystem effects doesn't show up with the intended particle texture, but instead shows up as a square instead of the texture I provided.
All 3 other CCParticleSystem effects are working properly though, just not this one, which is puzzling me.
I used Particle Designer for all 4 particle effects.
Anyone have any issues like this? Thanks for reading.
In my experience there are a couple of things that can cause issues like this:
There could be a resource missing from your build that was present in a previous build. Sometimes builds from XCode to device ignore resource deletions and updates.
You can check for this by doing an uninstall from the device, a clean in XCode, and then rebuilding to see if that makes the XCode build consistent with the TestFlight build.
If that doesn't help, then check the target membership of your particle resource and verify that it has been included in every build target that it should be (if you have multiple build targets).
Note that as a general rule, it is a good idea to do a clean within XCode prior to building an archive for distribution. This should ensure that the archive is always built using the latest sources and resource files.
I ran into a strange problem today, after renaming a couple of images in my app and making sure they work on a device as well as the simulator, I used Build and Archive as I always do to build my app to distribute to the testers.
However, this time I got strange reports from the testers saying the images were gone, so I installed the build on my phone and to my surprise they were gone as they said. Tried to do a clean and build again but no change.
When I open the .app archive I can clearly see that many, but not all, of the images have turned blank, they appear to be the same physical size on the disk and they also seem to have the correct height and with when I press space to preview them, I can't however open them with photoshop for example (the file-format module cannot parse the file).
This is very confusing and as I have to get the build ready for testing very soon I would very much appreciate some help in this matter.
Your source PNGs seem to be slightly off-standard or at least incompatible with Apple's pngcrush. Make sure you use a commonly well functioning tool for creating the PNGs - when in doubt reconvert/resave them.
I'm trying to use Time Profiler, I've used it before.
I'm hiding system libraries, but all of my symbol names are HEX.
I'm running in debug, I have debugSymbols turned on....
I've restarted everything a few times and cleaned everything in between..
... anybody got any other ideas?
it's a bit of a pain because there are a number of variables that can cause this. some of the more common ones are:
sometimes you need to tell instruments where to find your files and/or symbols (Preferences->Search Paths).
have you enabled Link Time Optimization (LTO)? it should be off.
sometimes it helps if you do a clean/build.
sometimes it helps if you restart instruments.
in earlier versions of Xcode, it helped to use a central build directory.
verify that you are generating the proper level of debug symbols for all targets.
I no longer get this problem with the latest version.
Apple were no help in answering this for me - even though I used one of my Tech Support Requests. Must have had them stumped too.