I m having some problem with my app which reproduces only when i install it ad hoc, but doesn't reproduce if i just run the app from Xcode. I would like to debug this problem, but so far i m not having any luck. I m using Xcode 5.1.1. Here is what i did:
1) Go to Product->Scheme->Edit Scheme->Archive and set build
configuration to Debug.
2) Code signing identity is set to iPhone Developer.
3) Generate Debug Symbols is set to Yes.
4) Go to Product->Archive and after it is archived, click
"Distribute", then choose "Save for Enterprise or Ad Hoc Deployment".
5) My development provisioning profile is selected.
6) Click "Export" and export the .ipa file.
7) Use iPhone configuration Utility to install the app onto the
device.
8) Run the app on the device.
9) In Xcode, go to Debug->Attach To Process->By PID or Name, enter the
app name. Xcode attaches successfully and says running the app on
iPad.
10) However, i cannot hit any breakpoints which should be hit when i
do certain actions in my app (if i install and run the app from Xcode
instead, all breakpoints are hit).
Am i missing something?
You don't have any debug information for the app at this point, and since most apps are pretty thoroughly stripped, there won't even be symbols for lldb to hook on to. So we're not going to be able to successfully set breakpoints.
When you built the app, Xcode produced a dSYM file (MyApp.app.dSYM) which has the debug info in it, so all is not lost. Problem is when you attach to some - to Xcode - random app on the device, Xcode has no way to know where to find its debug info.
You can add the debug info into your debug session in lldb by using the command:
(lldb) add-dsym <PathTo.dSYM>
You have to do this after you have attached.
lldb also uses SpotLight to find dSYM's so if you put the dSYM somewhere that SpotLight knows to search (like your Desktop or a folder under your User directory) then lldb should pick it up automatically.
You can tell whether lldb has successfully read in the dSYM by doing:
(lldb) image list <AppName>
If lldb found the dSYM, it will list the path to it on a separate line after listing the path to the AppName binary.
Jim Ingham, thanks for your answers.
I found the reason why i was unable to debug into static libraries. In each Xcode project, there is a setting called "Strip Linked Product" under "Deployment" section. In all my projects this setting was set to "Yes".
In order to debug into static libraries for an app built by archiving, i set this setting to "No" in each dependent library project (as well as the main project). This can also be set differently for Debug/Release modes. After this, i see the library symbols built during archiving and i m able to debug into library code. I hope this helps someone.
Unfortunately (or maybe fortunately) the bug i was trying to debug no longer reproduces when the library symbols are not stripped. Maybe something happens when the symbols are stripped, i will need to investigate further.
I was struggling with the same problem, and just launching my app from Xcode was not an option - I had to build the IPA, sideload it on an iOS device, and then debug. Eventually I was able to make that work with the following steps:
1) Set the scheme archive target to Debug
2) Change the following settings for the Debug builds
Keep Private External Symbols (KEEP_PRIVATE_EXTERNS) : YES
Enable Bitcode (ENABLE_BITCODE) : NO
Strip Linked Product (STRIP_INSTALLED_PRODUCT) : NO
3) Rebuild, archive, and deploy the resulting IPA file to your iOS device.
4) Launch the app, and in Xcode, select Debug/Attach to Process/YourAppName(id)
5) Break into the debugger - you should be able to see the code, put and use breakpoints, etc.
If you want to debug your code from the very beginning, just put a loop that sleeps for a second or two and then checks a flag at the top of your main function - when you break into the debugger, just change the flag to let it escape the loop.
Related
I have been trying to debug my objective-c code of a custom embedded framework I have been using/developing for the last years and recently (1-2 weeks ago) just before Xcode 10 was released all worked well. I was able to build my embedded framework with debug configuration, create an app (using NativeScript), deploy it to a simulator, open my framework's .xcodeproject, go to Debug > Attach to Process by PID or Name, select the app and add breakpoints int my objective-c code to debug it.
But today I tried to do the same and the breakpoints cannot be hit. I know my embedded framework is build in debug configuration because the .dSYM file is present. Also after the process is attached if I stop it using the button the app stops in the simulator so it must have attached correctly.
Has anyone faced such issues?
Edit:
I did verify that the embedded framework in the project contains debug symbols by comparing the output from nm -a <lib> and nm <lib> from this answer.
Edit 2:
The scenario is quite straight forward:
create an dynamic embedded framework
build its .framework and .framework.dSYS file
add it to a project's embedded frameworks
build that project into app
deploy it to a simulator
open the framework's project
attach it to the process
try to hit a breakpoint.
When you deploy it to the simulator, try stopping the xcode process and manually launch app from the simulator and then attach that Process. Refer to this answer for step by step instructions. How can I debug in a framework in Xcode?
After 3 days of research and digging around I managed to resolve this issue. The source of it still in unknown for me and it looks like it is some sort of breaking change of xcodebuild between 9.4.1 and 10 but it sounds like it could have very much been intentional or a bug fix.
Short answer:
Make sure that the .dSYM that you used with your fat library is for the correct device (simulator or a real device)
TL;DR
So the issue was that I was using the wrong .dSYM file when attaching to the simulator while the .dSYM file was taken from the xcodebuild for real device. So the steps in my build phase (done in bash) was the following:
Build the framework for simulators
Build the framework for real iphones
Create a fat library using xcrun using the above created .framework files
Copy the .dSYM from the real device location in derived data (this is wrong after XCode 10)
I see that this is incorrect but it never made any issues when doing the "Attach to Process" previously but in XCode 10 this no longer works (using debug symbols created for device with a simulator)
I developed an app with phonegap, and I hate to try on a apple device. I've jailbroken my iPhone5s for try my app without pay apple.
I follow this guide, but seems does't work:
On your Jailbroken device install AppSync Unified 5.2-1 (or later)
from AngelXWind’s repo. Don’t use any other AppSync, and if you have
others, be sure to remove them. Open
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist
and change AD_HOC_CODE_SIGNING_ALLOWED to YES. You may need to
duplicate it to the desktop, change it, save it, then drag and drop
back into the original folder because OS X let you edit the file in
place. If XCode was running, restart XCode. Change your Project and
Target settings to “Ad Hoc Code Sign” in Build Settings Tell XCode to
run app on iPhone. At this point XCode will put app on your iDevice,
but can’t debug because it can’t attach to the process. The app will
start then close immediately. You can now manually start the app on
the phone now though. To enable debugging: In your project select
File>New File Property List and create a file called
“Entitlements.plist”. Add “Can be debugged” or “get-task-allow” (both
do the same thing) and set the value to YES. Now change your Project
and Target Code Signing Entitlements (In Build Settings) to
“Entitlements.plist” (you have to type it in). Now XCode can run and
debug the app. Good luck
This is the link of the guide.
When I run app, XCode tell me "Build Success", and on top it says :"Running on Iphone". If I open detail, it say: "Preparing to install " with a loading circle. It's 20 minute that is preparing to install my app.
How can I fix this problem?
I've been getting a bunch of crash logs for my (largely c++) app on iOS. My problem is I can't seem to ever symbolicate these crash reports properly.
What is the "proper" setting for stripping debug symbols for release on iOS? I get that you'd want to strip the debug symbols so the download size of the app isn't ridiculously large.
But the problem is that it seems to make the crash reports virtually unreadable.
Do dSYM files on the xcode archives get sent and eventually downloaded by the users?
Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on xcode)?
Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on Xcode)?
This. Your "release" config (or whichever config you use for distribution) should have the following setting:
Symbols Hidden by Default: Yes
Xcode will still generate a dSYM folder which is what you will use for symbolicating crash logs. There are 3 ways to handle symbolicating:
Use Xcode. For this you need to use the Product -> Archive feature whenever you release. Once an archive is created, you can select "Export" then "Save for iOS App Store Deployment". After this you can drag crash logs into the left side of the "Device Logs" window and Xcode will symbolicate them for you.
Manually symbolicate using the symbolicatecrash tool located inside your Xcode.app folder. This is useful if you've released code to users but don't have an Xcode archive. You need to be sure that the crash log matches the binary and dSYM or it will not work.
Use a third party tool that collects crash reports and symbolicates them for you. Examples include Crashlytics, Bugsense, or HockeyApp.
Is there a way to debug a .ipa file after archiving?
I have a bug that I am running into when I archive to .ipa file that doesn't show up in xcode when I am running tests.
Thanks,
Presumably your testing is done with a Debug build, whereas your archive is a Release build? You can check this if you select 'Edit Scheme' from the schemes drop down in Xcode.
To test the archive build, you can change your "Run" setting to use a release build rather than debug - click on Run in the left hand panel from the Edit Scheme screen and then the Info tab and change the Build Configuration to Release.
Don't forget to turn it back to Debug once you have finished.
The thing is - it's pretty rare to find issues like this, could you perhaps explain more about what your problem actually is?
I'm starting to use Instruments-Leaks with an iPhone 3G. When I try to run the app with Instruments on the iPhone I obtain
Target failed to run: Remote exception encountered: 'Failed to get task for pid 280'
Ideas?
The only time I succeed in running the app with instruments it run very slow, I couldn't test it.
What are the steps to run the app on the device searching for leaks?
The solution for me was to make sure that my Profile scheme was using the "debug" and not "release" build configuration.
In Xcode 4 select Product/Edit Scheme from the top menu
then click on the "profile" button on the left.
On the "info" pane you will see a setting for Build Configuration- set that to "debug"
This error is also thrown if you are trying to test your app on a device with a distribution profile selected. Make sure you have the correct code-sign settings for development.
You CAN profile the release build on the device. What you have to do is build the release build with a developer certificate. See here.
Instruments basically does its work by becoming the debugger for the app. If you can't run Xcode's debugger against it, then you can't run Instruments against it.
Mostly, entitlements need to be set to allow debugging.
Sometimes after using XCode to debug apps, I find I can't use Instruments until I reboot the device.
Unlike XCode, Instruments can be confused between two apps with the same name, but different bundle IDs. (Or perhaps same name and similar bundle IDs.) When I have multiple versions of an app on a device, I often have to delete the extra to get Instruments to connect to the correct app. If you have one debug build and one release build, this could be the problem.
So, delete any duplicates of your app and restart the device. (You could change the display name for release and debug build configurations.)