I have a project I can successfully build/install using developer/debug to a device or simulator.
When I make an ad hoc build i can build-run onto the simulator, but not onto the device.
I'm trying to perform a direct install because the ad hoc installed app is crashing (nil added to array) where the debug version is not.
I also have tried to attach to the running ad hoc installed app. The app will run indefinitely (but crash if i perform a particular use case.) But if I attempt to attach to the running app, it will crash.
It happens to be a Box2d/Cocos2d application - but i don't have any reason to think they are the cause. Xcode 4.3.2, iPhone4 iOS 5.1
the message when build-and-run is attempted:
error: failed to launch '/Users/bshirley/Library/Developer/Xcode/DerivedData/foo-bar-evrbckppmbsspqhezhleaxkmymxn/Build/Products/Adhoc-iphoneos/foo-bar.app/foo-bar' -- failed to get the task for process 6892
Anyone have some insight into the problem or tracking it down?
Edit, I thought I'd add some key words so searches might be more likely to find:
One issue with diagnosing the post-mortem crash was that the stack trace was not symbolized in the Device Logs of the Organizer in Xcode. That left me with 6+ deep stack trace w/i my code and no real reason to determine where it actually was.
If it is a release build, the app will (in a default setup) have a flag preventing outside processes from hooking into it (for security reasons). This includes the debugger. If you try, you will get the exact error message you indicate.
EDIT Sorry, small error. A release build alone will not cause this. A build with an adhoc certificate will cause this, because it is meant for final install on a device (not debugging).
If borrrden is correct (and it seems reasonable that he is, connecting one app to a signed running app would be a security issue), I can't actively debug the adhoc app.
The most useful thing i found for tracking down this issue, is Build Settings -> Symbols Hidden by Default - this value is only NO for debug. Setting it for NO on adhoc allowed me to see the entire stack trace when inspecting the Device Logs in the Xcode Organizer.
That led me to the particular method that was invoking the crash causing issue. Which led to the question why wasn't it crashing in the debug build. Didn't have time to diagnose that, just fix the problem.
Related
I am facing a strange issue in my currently working app. App is crashing when we install app through diawi or directly install using .ipa . But I am not able to regenerate the issue through debugging. I am totally confused and how can I solve the issue?
I am using Xcode 8.2.1
You can try building the app in Xcode in the Release configuration instead of the Debug configuration.
You do this by
clicking on your app name at the top left (near where you press to run the app)
choosing 'Edit Scheme' from the drop down
clicking on the disclosure indicator by 'Run'
choosing 'Run' from the three choices which appear
there is a drop down called 'Build Configuration'. This will almost certainly be set to Debug. Set this to Release.
Now when you run your app you will be building a far more optimised version - this is the version you build when you are submitting to Apple. It's just the same app optimised for speed/memory instead of debugability.
Hopefully, you should be able to reproduce your crash in Xcode now. However, you'll notice that you get far less debugging information when you hit your crash - this is because Debug builds have lots of extra information in (and are much less optimised by the compiler) specifically to make debugging easier. Being able to reproduce the crash in Xcode should give you a few more clues as to what's going on. At the least you should be able to see the chunk of code causing you issues.
Let us know how you get on.
Use crash tracking tool to track crash here is the detail about installing crashlytics
I have an iOS app that is only crashing with the client on iOS8.0
At first I tried to install iOS simulator8.0 on my xcode7.0, OS X El Capitan to test the code but, facing some issues, I dropped the case
Now, what I am trying to do is get the crash log from xcode's organizer, but weird things are happening:
I am logged in xcode with my iTunes account
The app had the checkbox on for "Include app symbols for your application…" when uploading it to testflight, BUT the build details in iTunes Connect shows "Includes Symbols: NO"
The organizer does not show every versions of the app on iTunes Connect, although we can see all the versions and build numbers from my colleague's xcode.
Organizer doesn't show all the crash log of the app of the given build number although I can see some crashes on different builds (On the other hand, my colleague can not see any crash log happening on the app for the current version and for all the previous versions)
Can anyone help me on any (or both) of the issues? Thanks
NB: I want to avoid to ask the client to send me his device's crash logs. Although one time I asked a client for the crash log from the device and there wasn't any crash registered on the device
The reason you and your colleague do not see the same crash logs is likely
because your colleague is assigned a lesser role in your team.
(Say you are admin and he's technical)
Can't help with the Includes Symbols: NO issue cause I have
debug symbols stripping set to NO for both debug an release targets
and yet I see the exact same issue (Includes Symbols: NO in itc).
Apple just does not like to symbolicate I guess...
I am getting the following crash reports from some recent apps deployed to the app store. I am not sure what is causing it or how to fix it.
Could not load 'monotouch' for registration. This could be due to an
outdated assembly kept by the simulator, location:
/private/var/mobile/Applications/1BEDC27F-B313-4240-8490-EAD680F8E78A/PhotoTour.app/monotouch.dll
It refers to the Simulator in the error, but the app from the app store.
The message itself refers to a condition that was known to exists only in the simulator. The iOS Simulator does not remove old files (it only updates them).
In recent MonoTouch versions there's another fix now that should prevent even this message to occur (on simulator builds). It's very unlikely that the same condition (stale binaries) is occuring on devices.
The exception behind the error means that that the types inside the assembly (monotouch.dll) could not be registered properly. This should not happen, even less randomly (i.e. if it occurs it should be systematically on every execution and on every device, including when testing). Since registration occurs everytime at startup it's hard to see why testing (and Apple app approval) has not catched this.
Please fill a bug report including the exact version of MonoTouch being used and attach a log of the (release) build (add -v -v -v so we'll get more details about the build). Also attach the logs from where you gathered the above message - other lines of the same logs might gives us some clues.
I have an app which I deploy to a physical device. The build succeeds and the App gets installed. But right after the launch image I get the error failed to get the task for process 2284.
When I quit XCode and launch the application manually on the device it runs without problems.
The XCode console does not give me much valuable information (See Gist)
This gist shows what the console on the device recorded.
I figured out, that the problem occurs when I am debugging with a Distribution profile. When I create a non-Distribution provisioning profile for the App I can debug again.
I got this a few times and after rebooting the iPhone (and maybe your Mac as well) everything worked like before the trouble started.
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.)