I have a Mac app store app that just silently disappears when it crashes. It doesn't show the CrashReporter dialog to give the user a chance to report the crash to Apple.
I see the same behavior on multiple machines. Is there any known reason why this might happen?
According to TN2123:
In addition, if the program that crashed is running as a logged in GUI
user, CrashReporter will present the user with a dialog asking them
whether they want to submit a bug report to Apple
What does "running as a logged in GUI user" mean? Does a window have to be visible?
Update:
I was reading the manpage for ReportCrash, and found the following:
For application crashes (but not background process crashes)
ReportCrash will display a dialog notifying the user that the
application unexpectedly quit and offering to reopen the application
or send the report to Apple. For developers, the behavior of this
dialog can be adjusted using
/Developer/Applications/Utilities/CrashReporterPrefs.app which is
installed as part of the developer tools.
I ran CrashReporterPrefs and changed my CrashReporter mode to Developer. When I ran the app and triggered the crash, the CrashReporter dialog was shown!
So I guess the question now is: What's the difference between an "application" crash and a "background process" crash?
If your app uses LSUIElement or LSBackgroundOnly, it's a “background process” for the purpose of determining whether to show the Crash Reporter. (Other “background processes” include UNIX-land daemons, such as the Apache web server, and processes started from SSH or telnet connections.)
Since CrashReporterPrefs no longer comes with developer tools, you can change the behavior to show the dialog for daemons by running this command in the Terminal:
defaults write com.apple.CrashReporter DialogType Developer
Related
So I'm trying to track down an issue that crops up when I'm NOT debugging with Xcode on the Apple watch, and I've discovered that the Apple Watch has some serious problems with console output if it wasn't launched via the debugger. Given the following code:
- (IBAction)onPrint:(id)sender
{
NSLog(#"############## Printing! ##################");
printf("************** Printf! ******************\n");
}
When launching via the debugger, it shows both lines in Xcode's console window. Great, no problems there.
If, however, I launch the watch app manually (from the watch itself), I get nothing in the console log via the devices window in Xcode, and nothing in the Console app on the mac (other than the normal "kernel[0] : prevent idle sleep list" messages the watch emits to the console from time to time).
I also tried connecting to the watch extension process using the Debug -> Attach to Process menu in Xcode, but it still won't print anything. Clear console, reload console... nothing works. I've looked all over SO for answers, and tried everything marked as an accepted answer or not, but nothing seems to work. This app is as simple as it can get: A single button that executes the code above to print to the console.
Is it just broken? Or is there some other arcane magic I must weave? I'm running Xcode 8.1 and WatchOS 3.1 on an Apple Watch 2.
It looks like this is just a limitation of WatchOS. The only way I've been able to get data back is by storing logs in a file and then fetching the file later.
Thing that can help you is called sysanalyse: you'll have to add special profile to both iPhone and Watch, and this will allow to see your app's logs in Console and via sysanalyse reports. Instructions and profiles are provided here.
If you are debugging background tasks, important to know: watchos's daemon will not terminate process what had already used it's background execution time limit if it is connected to debugger.
This is really odd because I was able to see log statements on the console. It's just now, I'm not. This is for Watch OS 6, xcode 11.2.1.
I setup a bot to build the project then test on all the simulators. This has been working, but today the integration had 28 errors. Each said the same thing (but for each simulator device name):
Xcode cannot launch apps on the simulated device “Resizable iPad”, as
it is currently running an app on “iPhone 5s”. Only one simulated
device may be used at a time...
After manually running the bot I received no warnings. What could cause this? (I enjoy the success streak)
I only had one project running and had the same issue. Control Quit out of xcode and start it back up.
I had this same problem. I had multiple projects open and a different one still had
'Running appName on deviceName' displayed
Currently open projects can be accessed from the Window section on the toolbar on top. Pressing the Stop button (or the command from the Product Menu) on any projects that were still 'running' freed that particular device for other projects.
Alternatively, Rebooting Xcode works as it closes all projects.
See: https://stackoverflow.com/a/22267017/5172836
I encountered the same error today with the simulator.
The only way i've find is to reboot Xcode. After that the error disappeared and the application launch corectely in the simulator.
I don't know how the error has been originally produce, but Xcode is not a reliability model, so...
I'm building a Cocoa application with Xcode. I have to force-kill my app for unrelated reasons, and every time I do I get this popup:
The last time you opened MyApp, it unexpectedly quit while reopening windows. Do you want to try to reopen its windows again?
If you choose not to reopen windows, you may have to open and position the windows yourself.
[Don't Reopen] [Reopen]
What is this system called and how can I disable it for my application?
This is Cocoa's automatic state restoration in action. You can suppress it when your app is launched under Xcode by editing your active scheme, choosing the Run action, and checking "Launch application without state restoration".
Note: Disabling this will also disable automatically-reopening documents that were opened previously, which can be a pain for testing a document-based application, since you'll have to re-open the doc manually each time you run it. This also only disables state restoration while being run under Xcode under that particular scheme.
When something goes wrong in my Mac OS application, like a NULL pointer exception or something like that, OS X pops up a "problem report" window inviting the user to send a report of the problem to Apple. Is there any way to have the same information displayed in a window that prompts them to report it directly to us, instead?
Also, how do you get access to the reports people send? I assume it involves signing up for the mac OS developer program?
Can anyone point me to the documentation on how to make Instruments run UIAutomation scripts and start the iPhone application with the debugger running in the Simulator?
Constraints:
I only have iPhone 3g hardware to test with and debugging against the device with UIAutomation just does not reliably work.
Normally the test scripts are just ran to make sure everything passes, but now a weird bug exists that only gets triggered when the UIAutomation script runs (which is a good thing). The bug cannot be duplicated in manual operation.
There does not seem to be anyway to attach Instruments UIAutomation to a process already running in the simulator. There is no selection.
Starting Instruments UIAutomation directly does not cause it to start with the debugger.
I would assume that there is some command line magic that can be configured in Instruments edit active target (environment variable, arguments, working directory) to make this happen, but I've not found the magic paragraph.
Thanks,
Neil
This stumped me for a while, too -- especially since when the Automation Instrument is selected, the Instruments application explicitly says Current instrumentation disallows attach. The key is to realize that an app running in the simulator is visible in your host system as its own process, so attaching directly from GDB works well. These instructions are for XCode 4.2 (4C199) on Snow Leopard 10.6.8:
Start your test in Instruments however you normally do (either directly from Instruments, or from Xcode 4's Product -> Profile. Pick whatever templates and scripts to get your automated test underway.
Back in Xcode, under the menu Product -> Attach to Process, you should see your iOS app, listed by name, alongside all the other applications on your host computer. In fact, it very likely will be listed first, under the section header Likely Targets.
If it's not visible, choose View -> Debug Area -> Show Debug Area so you can see the gdb console.
Hit the pause button (Product -> Debug -> Pause) to interrupt your program. Set breakpoints, inspect, as usual.
Then next question is: why can't I see my normal NSLog() output in the debugger console?
Your app already bound itself to the console output streams, so the simplest place to look for its output is in OS X Console app (/Applications/Utilities/Console.app) and look under DATABASE SEARCHES -> All Messages.