I sent my first desktop OSX app out to a small circle of testers today. One user cannot get past the splash screen.
I am wondering how one might debug something like this? Would I somehow write NSLogs to a file? Or does OS X have some sort of utility? I assume I need some sort of logging capability, right?
You can write your logs to file quite easily (not via NSLog, but just plain writing NSString to disk via writeToFile if you want to). You can also have your logs automatically uploaded to your server if you have one using NSURLConnection with a POST.
I prefer the latter because it requires little intervention from the testers, and happens automatically.
Distribution builds are not ment to be debugged or else it would have been development build.
You can how ever sync your device with itunes and then get the crash report(if you want to know the source of crash).from appdata.
reffer to this link. if you want to debug make a debug build with development provisoning. in your case ask the tester to send you the crash report and you keep the ipa or app file safe you will need it to read the crash report.
Related
I apologize but I don't know the official name of the system I'm referring to, here is a screen shot showing the dialogs (note: Don't confuse "Shell" w/ Windows Shell, in this case "Shell" is the name of the my process that is crashing):
Two questions:
What is the name of the system/technology shown in the screen shot? Not the application that is crashing, but the system that is handling the crash, collecting the dump file and sending it.
If I have an application that for some reason I can't handle or catch all exceptions for, is there a way to redirect the sending of the crash data to a recipient I specify? Or register a handler or something? For example, if it were my application crashing and the user clicks the ''Send information'' button can I send that info to my email address or some other endpoint?
Most of your question has already been answered by #HansPassant:
That is the WER dialog, the crash activated Windows Error Reporting. A component written by Microsoft, it sends crash info to a server in Redmond. Microsoft uses it to fix the kind of bugs that they can fix. But most likely in your case it is your bug, they won't fix it. But you can get the info that WER gathered about it by following these guidelines.
Note that you need a code signing certificate to complete the registration and you need a few extra steps to identify your application. You'll only get small dumps (< ~1 MB), which sometimes don't help (often don't help for .NET).
#HansPassant also pointed out how to handle a crash yourself:
Or you create your own service, that must get started with SetUnhandledExceptionFilter() so you get the crash info before WER does.
However, there are a few more options to get the dump:
there is a Registry key called LocalDumps, which you can use to save dumps on a local disk. Please consider turning that on only if you need it, otherwise it'll easily fill your customer's hard disk. This works very fine if the crash is reproducible at the customer's site but not on your machine.
use a free library like CrashRpt (open source; please check the license) or Doctor Dump. This perhaps has the disadvantage that you need to set up a server to collect the data.
see more options which I described in the answer How do I take a good crash dump for .NET, which also works well for native applications.
I'm developing an application on MacOSX (using Qt) and my users starts to use it.
It writes a log to ~/Library/Logs/MyOrganization/MyProgram.log
I would like to be able to get the log and the crash information from the user in the easiest way possible for him.
Is there a way to handle application crash default dialog from Macos?
I found the killer module to perform what I want to do: https://github.com/tcurdt/feedbackreporter
We've got a fairly mature cross-platform game engine which we've had running on OSX for several years now without a hitch; we recently upgraded the game from SDL 1.2.15 to 2.0, and at some point in the conversion, I goofed something up and now we have a bizarre problem where the app launches just fine from the terminal, but when you launch the app from a double-click in the Finder, it just bounces once in the dock and just goes away.
We're baffled because insofar as I can tell, there's only a one-liner being printed in Console.app: Exited with code: 255 (naturally running from the terminal doesn't help here because we can't reproduce the problem there; the app runs fine when launched in a terminal).
So the only thing we can figure is it's either something we're goofing up in our main.cpp, or something we've hosed in how I set up the dylibs/frameworks. It's also possible that it's something to do with the working directory not being set right, but to the best of my abilities, I believe we're doing it right (regardless of your current working directory; the app attempts to forcibly set said directory to be in the Resources folder - this was necessary to get the game to launch, but I don't know if we're doing it wrong). This feels like a somewhat awkward fit for stackoverflow, for which I apologize, since it's not a simple "paste this code and ask what's wrong" job. I have two ways for you to reproduce it; firstly we are an open-source project, and you can get our source code (complete with a mac project file and all dependencies included in the repo, set up and ready-to-go exactly as I've perhaps erroneously created them), at our github page. The one change you'll need to do is open a file at the root level, named master-config.cfg, and remove the // comments from it (so the engine knows you want to launch a simple demo game shipped with the engine).
Alternately, I have a stripped down (~15mb zipped) binary you can directly download and try to run, if that's sufficient to diagnose the problem.
As said before, we're open-source, so we welcome any pull-requests for fixes!
You need to write a minimal Cocoa wrapper so that OS X will not SIGKILL you for not launching properly. I will give you a pull request with that wrapper.
I have a problem with my Windows Phone app.
The app uses all the device sensors: gps, accelerometer and compass
When I run it in the emulator it's fine and when I debug it on the phone it's fine.
But when I remove the USB cable from the device and start the app again it crashes very soon and I dont know how to find out why because the debugger is not attached.
How can I debug such a problem?
There are a number of reasons that this can happen. It's hard to pinpoint precisely what's going on without some debug output, but here is a brief run down of the likely culprits:
Most Likely...
The most likely thing that's causing your app to crash in non-debug mode is poor start up time. I suspect you may be encountering what this S.O. question is all about. When the debugger is attached, the runtime bypasses the operating system's function of killing any app that takes longer than 10 seconds to load. This is an easy thing to test for, simply remove all the code that's being executed when the app starts up (I'm assuming you're hooking into GPS stuff at that moment, just comment that stuff out).
But Additionally...
While the above might solve your problem, you have to be wary of a few other issues you may also encounter:
When you access the GPS / Accelerometer / Compass you must check first to see if those sensors are actually accessible and provided by the phone. Not all windows phones are required to provide the compass. Take a look at the Hardware Specifications for Windows Phone. If you are trying to access the compass, and your device does not support the compass, then that could be your problem right there. More details on this here. The following code is an example of how you might check for the presence of the Compass on the device (note that the IsSupported will return true even if your device has the compass off).
using Microsoft.Device.Sensors;
public partial class MainPage : PhoneApplicationPage
{
Compass compass;
public MainPage()
{
if (Compass.IsSupported)
{
// awesome. you have a compass
}
else
{
// uh oh… you have a crappy phone, no compass for you :(
}
}
}
Have You Tried Turning It On And Off Again?
One of the other things you have to consider is that the device you are using has the GPS turned off (greater developers than you I am certain have made more foolish mistakes). If your GPS is turned off, or disabled, or the user (you, there, holding the device) has not authorized the app to use GPS data. See this article for dealing with the location considerations alone (a must-read if you're developing GPS enabled WP7 apps anyways).
Declare Your Intentions Sir
Lastly, there can be issues if you don't declare the things you're accessing from the device in the application manifest file. Basically, if you don't declare those as items your app uses, you can run into problems. The reason you need to declare what you're app uses is so that Microsoft can appropriately filter/warn/inform users who are downloading your app from the marketplace of the information your app requires to operate.
Battery Saver Mode
When a Windows Phone is in battery saver mode some of the sensors will be turned off to save battery life (things like... GPS, Compass, and Accelerometer). This could easily happen if your device isn't actually charging when it's plugged into your dev machine.
In Summary:
Check to see if your app is taking longer than 10 seconds to load
Make sure the device actually supports the sensors you are trying to access
Make sure that the data returned by the sensors is not causing your code to crash (for instance GPS may be on, but give a lat/long that is, according to your code errant, causing it to crash).
Make sure you declare usages in the application manifest file
Make sure your sensors are ON and you're not in battery saver mode
Hopefully one or all of the above helps you diagnose your problem. Lemme know if you find out that it's something else, would be curious to know what else could be causing this problem.
Have you considered adding MessageBox.Show method calls in any exception handling code you may have to display the particular exception message and even the stack trace? Also consider doing the same for the Application_UnhandledException event handler in the App.xaml.cs.
What you can do is to write all Debug-Informations like the Stacktrace and the Message into the IsolatedStorage which then you can display on a seperate Page.
The Problem may arise because the Phone uses the Internet of the PC if plugged in (Had the same Problem for quite a time)
It's worth using the Little Watson technique described by Andy Pennell in his blog here. This saves the exception details to Isolated Storage and will email it out from the app when the application next starts. There's full code in the blog.
The code is easy to adapt if you want to remove the emailing part and just want to manually pull the crash details from Isolated Storage from your development PC.
I have a cocoa app which uses core data. Everything seems to be working fine.
However, in a very specific scenario the app was behaving very strangely for our client.
In particular the logs shows this appearing in the output many times (which I've never seen in my testing):
Core Data: annotation: -executeRequest: encountered exception = Updating max pk failed: with userInfo = {
NSSQLiteErrorDomain = 14;
}
Has anyone ever seen this message and do you know what it means? I've tried googling it but found no information other than a few message boards regarding the Growl app having similar problems, with no solution yet available.
Sorry that I can't be more specific regarding what causes this as I'm not even sure myself. I know how to reproduce this on the client's machine but this message seems very random.
I was hoping someone could give me some more information as to what this error means exactly so that I can maybe narrow it down some more. Right now I'm pretty clueless.
Note: This appears on a macbook pro running 10.7.2 (if that matters).
Thanks for any kind of help you can provide, even something vague would help me at this point.
Update:
The managed context "save" method also fails with the following error:
The operation couldn’t be completed. (Cocoa error 134030.)
This is not really a Core Data problem as such, but more an issue of you process running out of file descriptors.
Each process has a limited number of file descriptors. If you run out, Core Data (and many other things) will stop working, because they can no longer open files -- any they'll fail.
First of all, make sure you're not leaking file descriptors, i.e. make sure you close files when you no longer need them.
I'm not sure what kind of changes you're trying to track. Take a look at Tracking File-System Changes.
If you're on 10.7, take a look at dispatch sources and DISPATCH_SOURCE_TYPE_VNODE for a very powerful tool to track file system changes (corresponds to kqueue, but is easier to use).
Core Data also gives this error in a Sandboxed app when it tries to save DB to a location where it doesn't have full read/write access to (if a user opens file for example, Core Data will be able to read/write this file, but not anything else to the same folder).
Core Data fails to write the temporary _journal file to this folder and reports this error.