I have an application in Windows Phone 8.1. I debug it in an actual device and it works ok. However, when I run the app outside the visual studio, sometimes (random) it crashes.
Is there any way to see if there is an exception? In Android and iOS you can see the log although application is not running on Debug.
I think maybe it could be a memory problem, I load a lot of data. How can I check if this is the problem?
Thank you very much
There is no automatic logging for you, but you can use the global exception event:
Application.Current.UnhandledException += ...
There you can get your exception: Put it in a log file, just show a message dialog, etc.
I found a solution, where I was getting not enough quota is available to process this command windows phone 8.1
Windows phone 8.1 have bug for navigate frame.
I replaced :
Frame.Navigate(typeof(SecondXAML));
To :
await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => Frame.Navigate(typeof(SecondXAML)));
guys now no above exception. not enough quota is available to process this command windows phone 8.1
Tested 100 times calling. not crashing.
Related
I have created a Xamarin.Forms barcode scanning app with Android and iOS projects. The Android build appears to run fine, but the iOS build occasionally crashes and I am struggling to pin down the cause, as no crash log is produced and no exception is reported in the application output.
Under heavy load (non-stop barcode scanning) the app crashes after typically 200 or 300 barcodes have been scanned.
I am puzzled how such a crash can occur, leaving absolutely no evidence of its cause. Is there somewhere else I should be looking for the evidence, apart from within Xcode's Devices window? Shouldn't I expect an exception to be reported in the application output, while debugging?
I have implemented logging handlers for AppDomain.CurrentDomain.UnhandledException and TaskScheduler.UnobservedTaskException but they don't appear to be called. Is there some other way I can instrument my code to trap the cause of this crash?
Many thanks for your advice,
Tim
To get some output I always hit the continue button in visual studio debugger. The application stops, and for some reason I can see an exception in the output. Hope this helps.
The Xamarin debugging documentation indicates:
Use Xamarin Studio's native debugging support for debugging C# and
other managed languages code and use LLDB when you need to debug C,
C++ or Objective C codethat you might be linking with your Xamarin.iOS
project.
However I cannot find any documentation on how to use LLDB to debug a Xamarin app. If I run my app in the iPhone Simulator and try to attach to it using LLDB I get the following error:
(lldb) attach --pid 37993
Process 37993 exited with status = -1 (0xffffffff) lost connection
error: attach failed: lost connection
Attaching using Xcode doesn't work either. I tried different variations of attach but none of them worked.
Can someone point me in the correct direction on how to debug Xamarin apps with LLDB? Moreover is this something I could do on the device and not just in the simulator? I didn't find any information on how to use LLDB to attach to a process on a device.
Update
It looks like the debugserver process is crashing whenever I use lldb to connect to my binary. Here is a link to the crash report for debugserver:
https://www.dropbox.com/s/9lizhl2quj9n0cc/debugserver_2015-07-07-131423_gauss.crash?dl=0
Update 2
When I run dtruss on the app it prints the system calls till it encounters
dtrace: error on enabled probe ID 2475 (ID 194: syscall::ptrace:return): invalid user access in action #5 at DIF offset 0
which happens when something calls ptrace(PT_DENY_ATTACH, 0, 0, 0); Why is PT_DENY_ATTACH called?
Update 3
I traced the ptrace system call to this function: mono_assembly_init_with_opt which happens very early in the life of the program. All that function does is call ptrace, so if I just return early from that function, I can debug with lldb.
Basically, I can do:
(lldb) process attach --name AppName --waitfor
# when the process starts
(lldb) b mono_assembly_init_with_opt
(lldb) c
# when the thread breaks
(lldb) thread return 0
(lldb) c
and now I can happily debug with lldb.
But, I shouldn't have to do this. Is there something wrong with my project config (I can debug simpler apps with lldb) or is Xamarin being evil?
Codesigned apps on Mac OS X can only be debugged if they have a particular attribute set in their app plist. You want something that looks like:
<key>SecTaskAccess</key>
<array>
<string>allowed</string>
<string>debug</string>
</array>
You can look at the man page for taskgated for a somewhat terse description of this process.
Usually for Xcode projects, this attribute gets consed up and inserted into your debug builds by Xcode, so you don't need to do anything to get this to happen.
I don't know how Xamarin works, but it is possible that it is not setting this attribute. On older OS X systems, root can debug anything, so you could try sudo -s and then debugging from there. But starting with Yosemite, the request not to be debugged is being more broadly honored...
Have you tried using the pid from the Activity Monitor? Just type your app name into the search box in Activity Monitor when running it in Debug.
If it still doesnt work can you try just creating a new project and attaching to that just to rule out any project config.
This happens to be a limitation imposed by Xamarin in the trial version. After upgrading to a paid license, this is no longer an issue. Even though Xamarin's website says:
When you begin a Xamarin Trial, you get access to the full Xamarin
Business feature set for 30 days.
It's clearly not the full feature set since they explicitly disable attaching lldb to the app if you are using a native library. I'm not sure the reason for doing so, maybe someone from Xamarin can comment on it.
Explanation
Thanks to Jim Ingham for pointing me in the right direction. The way Xamarin events debuggers from attaching to the app is by calling ptrace with PT_DENY_ATTACH. This system call enables the process to deny requests for debugging. (Detailed Explanation).
Moreover rather than calling the ptrace function directly, Xamarin tries to hide the call by using the syscall method (link).
Workaround
If you really need to debug your app and are still using the trial version, here is a workaround. The ptrace system call is made in the function mono_assembly_init_with_opt which happens very early in the life of the program. That function doesn't do anything else and can be skipped. Since the function is called right in the beginning of the process, we need to attach lldb before the function is called.
The steps are as follows:
Start lldb and wait for the app to start.
When the app starts, add a break point for mono_assembly_init_with_opt
Resume the app and when it stops at that function, return early without executing that function.
After this you can use lldb or attach Xcode to the app and debug your native code as usual.
Steps in lldb:
(lldb) process attach --name AppName --waitfor
(lldb) b mono_assembly_init_with_opt
(lldb) c
# when the thread breaks
(lldb) thread return 0
(lldb) c
I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.
I have a problem that when I try to debug my iOS app with VS2013 (with Xamarin) I get the following error:
The program 'Mono' has exited with code 0 (0x0).
I am aware of the following answer. Cleaning the solution does solve the problem but then the next time I debug I need to do it again...
Would really appreciate if someone has a long term solution.
Is it crashing during launch? You've only got 10 seconds to launch and complete the FinishLaunching method in the AppDelegate, otherwise iOS terminates the app. This restriction doesn't apply in the simulator. If you've got a breakpoint in code that is running in this 10 second window, there's a very high likelihood that the app will be terminated unless you're very quick to continue.
I've also found that having breakpoints set anywhere in the app can add a few seconds to the launch time while the debugger hooks everything up. If your app is big or uses a framework like MvvmCross (which can take several seconds to initialise), you can be in a position where every millisecond helps.
If you can, let the app launch, then set any breakpoints. But if you're trying to debug your startup code, that's far from easy.
If you are using the Visual Studio Android Emulator: have you tried check "Migrate to a physical computer with a different processor version" in Hyper-V?
I got this trick from here Fix for Could Not Connect To Debugger
I have an app I'm developing where setting a breakpoint in Xcode while the app is running causes it to crash. At least I assume it is a crash. There is nothing in the console saying what happened. The app just terminates.
Note that the break point is not being hit, just the act of setting it causes this.
I've developed many apps and this is the first to act like this. Does anyone have any ideas what could be happening or how to figure this out? It is really slowing down my debugging.
I'm assuming you're using Xcode 4.x. Try going into your scheme's settings and switch to a different debugger (GDB if you have LLDB currently set, or vice versa).
If that doesn't work, we need more info:
which version of Xcode and iOS are you using?
does the problem occur in the Simulator or on your device, or both?
have you tried placing a breakpoint in different places in your code?
As far as I can tell, it's a debugger issue. So your app does not actually crash, it's the debug session that crashes which causes the app to terminate. You can observe a similar effect when you hit Stop in Xcode or disconnect your device while an app is attached to the debugger in Xcode.
Might be an issue with mismatching Xcode and iOS versions. Please provide more info about your environment to help diagnose the problem.