How do I pause my app until a crash report has been submitted? - objective-c

Background
I'm using UKCrashReporter in my app.
I've installed my own Uncaught
Exception Handler.
I'm setting up the
managedObjectContext of the object
activeItemController in
applicationDidFinishLaunching (1)
The Problem
If the managedObjectContext method throws an exception, the crash reporter dialog box only flashes up before the app crashes and so the user never gets to report the crash.
I want my app to continue only after the crash has been reported, not whilst the window is showing.
What I've tried
If UKCrashReporterCheckForCrash()
were an objective C method, I assume
I could call
performSelectorOnMainThread:waitUntilDone:YES
but it's not.
I've looked at some other Stack
Overflow questions about using
Conditional Locks to pause apps,
but I can't understand how I'd use it
for a C function.
How would I go about doing this in a nice way? Do people have any advice
for me? Any responses would be much
appreciated.
The Code
// In app delegate
-(void)applicationWillFinishLaunching:(NSNotification *)aNotification {
UKCrashReporterCheckForCrash(); // A C function which then creates a window if
// it detects a crash has happened.
}
-(void)applicationDidFinishLaunching:(NSNotification *)aNotification {
[activeItemController setMoContextDisk:[self managedObjectContext]];
[activeItemController setMoContextMemory:[self managedObjectContextMemory]];
}
Update 1
I've been asked for more details on what I'm trying to do, so here goes.
The bug that triggered this thinking was an exception when merging managedObjectModels. My app got caught in a loop printing "Uncaught exception" to the console every few milliseconds.
And when I installed the uncaught exception handler before this exception happened, I'd get the described behaviour - my app would fire up, display the crash report dialog briefly, then continue to load and crash again.
Summary - I want to be able to handle errors that happen on startup.
(1) I'm not using bindings to do this, as I thought bindings would make testing the class more problematic.

I think your problem is with thinking of it as "pausing" your app. Think of it more as a different initial UI state. Your attempts to block the run loop will prevent any interactive window from ... well, being interactive. :-)
Your best bet is to show your main UI (and connect data sources, etc) only if the "am I prompting the user to submit a crash report" method says "no, go ahead and start normally". Otherwise, show your window and, when the user sends or declines to send the report, close the window and ask your app controller to continue the normal startup.
I looked at UKCrashReporterCheckForCrash() and it doesn't appear to create a window of any kind. It merely submits the crash. Could you describe what you're doing with more detail?

Related

UI Automation Error: UI TESTING FAILURE-APP failed to quiesce within 30.0s

Since xCode updated i'm having trouble running any ui test case. It gives me this error when its expected to do a simple tapping action for example:
XCUIApplication *app = [[XCUIApplication alloc] init];
XCUIElement *passwordSecureTextField = app.secureTextFields[#"Password"];
[passwordSecureTextField tap];
Anyone have any ideas why am i getting this error? I've searched on google and here but haven't found any solutions.
Thank you.
Make sure you don't have any animations on screen during UI Automation tests. We had a text alert flashing on the login screen for debug/test builds of our app, and it would cause the "failed to quiesce" error until it was removed.
There are some other posts about this error that mention issues with UIRefreshControl, so I would suspect animating that or UIActivityIndicatorView would cause the same problem.
It might help to turn on the "All Exceptions" breakpoint. I used it and I recall getting the same error. It will break at the line with the problematic code and should show you the stack trace of the error with more info.
I had a similar error - as well as the simulator running very slowly. In my case it was fixed very simply by the method given in the accepted answer here: Xcode simulator extremely slow.
To save you a click: The issue was that I had accidentally pressed Cmd + T at some point, enabling "Slow animations".
I had to turn off the "Personal Hotspot" in order to get a working test environment (Because the blue bar in the top apparently disturbed XCTestRunner)
But as some tests need internet connection I can't do testing when being in the wild:-(
Anthony F's answer says it all. Likely something is still animating. The system seems to wait for the app UI to "settle" (go idle) and when that happens, it performs the tap action. However, when the UI constantly runs animations, it will never settle.
Xcode Console Output
Enable the console output in Xcode to see what happens when running the test.
Below is an example of the log, when it works well. The system waits for the app to go idle and when that has happened, it goes to find the button in the hierarchy.
t = 16.95s Tap "#go" Button
t = 16.95s Wait for app to idle
t = 17.00s Find the "#go" Button
t = 17.00s Snapshot accessibility hierarchy for XXX
t = 17.09s Find: Descendants matching type Button
t = 17.09s Find: Elements matching predicate '"#go" IN identifiers'
t = 17.10s Wait for app to idle
t = 17.15s Synthesize event
t = 17.41s Wait for app to idle
Below is an example when it fails. The system waits for the app to settle so that it can look for the button in the hierarchy. Since, it does not settle, it waits "forever" finally running into the timeout.
t = 18.88s Set device orientation to Unknown
t = 18.93s Tap "#go" Button
t = 18.93s Wait for app to idle
t = 79.00s Assertion Failure: UI Testing Failure - App failed to quiesce within 60s
In my case the "failed to quiesce" was caused, because at time t=18.90s, demo data was generated which caused repeated updates of a UIProgressView. From then on the app UI never settled ("quiesced").
("quiesce" as a word is not in my active vocabulary, which certainly has delayed my recognition of what was going on. The console output pushed me into the right direction. I'd bet "idle" rings more bells than "quiesce" for many developers.)

iOS9 storyboard what is unhandled action (handleNonLaunchSpecificActions)?

I've noticed the following error popping up in the console when running my app on iOS 9 when using a storyboard. I'm using xCode7. Is this something I need to be concerned about?
-[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] ** unhandled action -> <FBSSceneSnapshotAction: 0x176bfb20> {
handler = remote;
info = <BSSettings: 0x176a5d90> {
(1) = 5;
};
}
There is nothing wrong with your code. This is a logging message internal to Apple, and you should file a radar about it.
There are two hints that show that this is probably Apple's code:
The underscore leading the method name _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion is a convention indicating that the method is private/internal to the class that it's declared in. (See this comment.)
It's reasonable to guess that the two letter prefix in FBSSceneSnapshotAction is shorthand for FrontBoard, which according to Rene Ritchie in "iOS 9 wish-list: Guest Mode" is part of the whole family of software related to launching apps:
With iOS 8, Apple refactored its system manager, SpringBoard, into several smaller, more focused components. In addition to BackBoard, which was already spun off to handle background tasks, they added Frontboard for foreground tasks. They also added PreBoard to handle the Lock screen under secure, encrypted conditions. [...]
I have no idea what the BS prefix in BSSettings is for, but
BS is shorthand for BackBoard Settings, and an analysis of this log message would indicate that it's not anything you did, and you should file a radar with steps to reproduce the logging message.
If you want to try and grab a stack trace, you can implement the category linked to here. Some would argue that overriding private API is a bad idea, but in this case a temporary injection to grab a stack trace can't be too harmful.
EDIT:
But, we still want to know what this action is. So I put a breakpoint on -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion] and started printing out register values and found a class called FBSceneImpl which had a whole bunch of information about my application:
We are able to find out which private method is called next (stored in the program counter, instruction pointer, register 15.)
I tried finding the un-handled FBSceneSnapshotAction referenced in the log, but no dice. Then, I subclassed UIApplication, and overrode _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion. Now I was able to get at the action directly, but still, we don't know what it is.
Then, I looked at the FBSceneSnapshotAction again. Turns out it has a superclass called BSAction.
Then I wrote a tool similar to RuntimeBrowser and looked up all of the subclasses of BSAction. It turns out that there's quite a list of them:
The two method names we have (one from the log and one from the program counter on the devices) indicate that these actions are used under the hood for passing actions around the system.
Some actions are probably sent up to the app delegate's callbacks, while others are handled internally.
What's happening here is that there is an action that wasn't handled correctly and the system is noting it. We weren't supposed to see it, apparently.
AFAIK, the info above is related to iOS during snapshot the screen (i suppose for double click home multitask related behaviour).I deeply investigated my application and seems that it does not get any side behaviours. You can safely ignore it, for now.
You can use the following gist simple category to test yourself against the calls to the above function:
I have figured it out, it will happen when you have IBAction method declared in .h or .m file but you have not bind it to any control.
.m example:
- (IBAction)click:(id)sender{
}
but not assigned this method to any control in storyboard.
haven't find out why it happens in my app, but at least you can catch the exception, if you want to keep this from popping up in your log pane. It's not a solution, but it might give you more insight why it is happing by inspecting any of the arguments that are passed in the catch.
swift 2 version:
import UIKit
extension UIApplication {
func _handleNonLaunchSpecificActions(arg1: AnyObject, forScene arg2: AnyObject, withTransitionContext arg3: AnyObject, completion completionHandler: () -> Void) {
//whatever you want to do in this catch
print("handleNonLaunchSpecificActions catched")
}
}

WinJS app with an uncatchable crash

I have random crashes in my WinJS application when navigating between pages.
The problem is that these crashes never occurs when the app is attached to the Visual Studio debugger; so I can't find where they come from.
I use the WinJS.Application.onerror event to prevent crashes, and log what happens, but as this works well when I try with a random exception, my "uncatchable" crashes doesn't seem to fire this event (I don't have anything logged).
Do you have any idea of what could cause these crashes, or any solution to find more informations ?
Sometimes errors can't fire the WinJS.Application.onerror for several reasons (in my app, the problem was in an iframe, in a page not using winjs).
When it happens, errors can be found in the event log, under "administrative events"
Found this on this link :
http://www.davepaquette.com/archive/2012/09/15/windows-8-store-app-crash-logs.aspx
Jason gives a good solution to this problem in this video (start at time 14:48). In his example, the app was crashing if you had a callback and navigated to a different page before the callback completed. Could this be the case for your app? Any more details on what is going on when you navigate?
For others (since it seems you already know about this!):
To be able to debug easier, use the WinJS.Application.OnError event. Wire up an event handler that dumps out information about the problem before the app crashes.
WinJS.Application.onerror = function (info) {
var err = {
errorMessage: info.detail.errorMessage,
errorUrl: info.detail.errorUrl,
errorLine: info.detail.errorLine,
errorCharacter: info.detail.errorCharacter,
};
Windows.Storage.ApplicationData.current.localFolder
.createFileAsync("crash.txt", Windows.Storage.CreationCollisionOption.openIfExists)
.then(function (file) {
Windows.Storage.FileIO.appendLinesAsync(file, [JSON.stringify(err)]);
});
};
The final stop for exceptions in JavaScript is actually window.onerror; not every exception will get thrown through WinJS.Application.onerror. Try hooking window.onerror directly.

iOS UIWebView - trap exceptions loading invalid file format

I have a UIViewController containing a UIWebView which I am using to view various documents. Occasionally a document may attempt to be loaded which is not supported by the UIWebView (e.g. old Excel 2.0 sheet). Currently this causes output in the debug window as follows :
exception: CPMessageException: The file format is invalid.
EXCEPTION CPMessageException: (null)
The webViewDidStartLoad method fires, but neither webViewDidFinishLoad or didFailLoadWithError fires.
The error doesn't crash the app, but I would like to trap this exception to provide my own message for the user. Can anybody suggest how to trap and handle this?
Many thanks,
Jonathan
Unfortunately CPMessageException is part of the private frameworks of Apple, in case of office files, OfficeImport.framework. This is thrown when the framework receives an unusable file.
The reason your application is not crashing is because it is probably being handled in the import code itself. Even setting NSSetUncaughtExceptionHandler will not work (as I have tried in the past).
The best way to go around this would be to use the shouldStartLoadWithRequest delegate method of UIWebView:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
Here you could preemptively stop the file from being loaded into the web view and avoid a clueless blank screen.
(Am not sure if there is a way to read NSLog output on the fly so you could monitor it. But that is probably not a right way to do it!)
Update: Just filed a bug regarding this. Let us see what the Apple Developers have to say on this.

CAsyncSocketEx + console application ?

I have console applicaiotn that currently uses CAsyncSocket.
I need to implement SSL so after some searching I found this project: http://www.codeproject.com/Articles/3915/CAsyncSslSocketLayer-SSL-layer-class-for-CAsyncSoc
For some reason same simple code that works fine on GUI code does not work in console app.
Has anyone exp. with CAsyncSslSocketLayer ?
Thanks.
CAsyncSocketEx uses a window as a sort of cheap thread to handle the event notifications that come from select(). Unfortunately, if you don't have a message loop, then the window which it creates will not receive these events.
http://support.microsoft.com/kb/90975
This article explains that a call to CreateWindow() needs to be called from a thread which has a message loop. And if you don't, then anything sent via PostMessage() won't get there.
I've recently started to tinker with this -- I want to remove the annoying hidden window and replace it with a normal thread. Their code relies on WSAAsyncSelect() in order to receive socket events... to a window. Yuk!
It's been a while since I had the same problem, but if I remember correctly, to use CAsyncSocket in a console app you need to add something like DECLARE_CONSOLEAPP (first two links shown below) to your console app. This should give your console a message pump to generate the socket notifications (OnReceive, etc.) GUI apps have these pumps but console apps don't, generally. The third (msdn) link below might also apply, it has more info and a different way.
If these still don't work, you should put breakpoints in your socket code and make sure your socket isn't instantiated in a thread or callback other than the main console app (the one that now has the message pump).
I think googling around for 'CAsyncSocket WinApp' or 'CAsyncSocket console app' would show more.
http://www.codeguru.com/cpp/misc/misc/consoleapps/article.php/c243/Console-app-using-MFC.htm
http://troels.knakkergaard.dk/code.htm
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/a6f1b72a-21d8-4046-a3dc-d7d29ece2ef6