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 (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to