Re: iOS 8: Can any of you guys think of why an async creation of a UIAlert would generate an exception on a show?
Re: iOS 8: Can any of you guys think of why an async creation of a UIAlert would generate an exception on a show?
- Subject: Re: iOS 8: Can any of you guys think of why an async creation of a UIAlert would generate an exception on a show?
- From: Alex Zavatone <email@hidden>
- Date: Thu, 30 Jul 2015 13:13:26 -0400
I've got the header info form two of the spam emails from the hijacked threads
As far as I can tell, it's being sent by meetsecret.net
X-Virus-Scanned: Debian amavisd-new at ns1.meetsecret.net
If anyone wants me to send them the header info or the complete emails, just let me know.
Setting up an individual filter for that domain in the header is certainly possible, but for everyone to do it, it's a waste of our precious time.
On Jul 29, 2015, at 2:40 PM, Alex Zavatone wrote:
> Huh. Within the @try block, we can see that the navigationControllerSupportedInterfaceOrientations: is being sent to the UIAlertController.
>
> 2015-07-29 14:15:56.967[719:244869] -[SignInViewController displayErrorMessage:] [Line 289] <- ***
> 2015-07-29 14:15:56.985 [719:244869] -[UIAlertController navigationControllerSupportedInterfaceOrientations:]: unrecognized selector sent to instance 0x156e29f0
>
> 0x156e29f0 is _alertController inside the instance of alert.
>
> Yes, the view controller class this is happening in is conforming to UINavigationControllerDelegate and I have set the self.navigationController.delegate to self.
>
> What I can't wrap my head around is why or how it is possible for something like this to happen.
>
>
>
> On Jul 29, 2015, at 2:08 PM, Alex Zavatone wrote:
>
>> I've got a completion block in an NSURLSessionDataTask that checks if the NSURLResponse statusCode is not 200 and in that case, it places a cell to a method to display a generic error message like so:
>>
>> // If no error occurs, check the HTTP status code.
>> NSInteger HTTPStatusCode = [(NSHTTPURLResponse *)response statusCode];
>>
>> // If it's other than 200, then show it on the console.
>> if (HTTPStatusCode != 200) {
>> DLog(@"HTTP status code = %ld", (long)HTTPStatusCode);
>> NSString *errorMessage = [NSHTTPURLResponse localizedStringForStatusCode:HTTPStatusCode];
>> DLog(@"HTTP error message is: %@", errorMessage);
>>
>> // display error message;
>> [self displayErrorMessage:errorMessage];
>> return;
>> }
>>
>>
>> And in displayErrorMessage is will asks GDC to dispatch an async call to display the message on the main thread.
>>
>> // Error messages
>> - (void)displayErrorMessage:(NSString *)errorMessage {
>> DLog(@"<- ***");
>> // handle on the main thread
>> dispatch_async(dispatch_get_main_queue(), ^{
>> NSString *internalErrorMessage = @"An error occurred. Please try again.";
>>
>> UIAlertView *alert = [[UIAlertView alloc]
>> initWithTitle: nil
>> message: internalErrorMessage
>> delegate: nil
>> cancelButtonTitle: @"OK"
>> otherButtonTitles: nil, nil];
>>
>> if (alert) {
>> [alert show];
>> } else {
>> DLog(@"For some reason, the alert instance isn't ready for a show.");
>> }
>> });
>> }
>>
>> What's happening intermittently when I'm causing the server call to time out is that I'll get a bad access on the [alert show].
>>
>> I've spent all morning trying to narrow this down, to find out where the bad access is and why this is occurring. Sometimes in the stack trace, I'll see 3 or 4 calls to display the alert in different threads. Sometimes, I see that the [alert show] exception is being caused by navigationControllersupportedInderfaceOrientations: being sent to alert and the instruction pointer is on the [alert show line].
>>
>> I've included a screenshot of thread 1 to see if any of this makes any sense to anyone else.
>>
>> Thanks in advance if you're able to spend some time to help me out on this one.
>>
>> Adding an @try block around the [alert show] and retesting now.
>>
>> Stack trace screenshot below:
>> http://i.imgur.com/KfILPLE.png
>>
>> - Alex Zavaotne
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden