UITextView autolayout goes crazy after a call to bindToEventNamed:

[sfaragnaus]

It seems that after a couple of call to bindToEventName:, selecting a UITextView for text insertion break its auto-layout constraints and position itself in apparently random position. I've attached a stripped down version of my project that exhibit this strange behaviour and a screenshot of the problem. To reproduce (you can use simulator):

• change #define PUSHER_APP_KEY @"INSERT_YOUR_APP_KEY_HERE" and substitute your testing pusher app key inside the quotes in line 18 of file CustomData.h
• launch the app
• (if a popup opens after 5 secs from launch, select 'Non Ora')
• tap on the middle icon on the bottom (the one with 'IBA' impressed)
• tap on button in the lower left portion (i.e. back arrow)
• tap on the little icon in the lower right part (the little arrow pointing inside the semicircle)
• click on any TextVIew to show the keyboard, the problem should present

I've found that this happens only if I execute the call to bindToEventNamed: in line 305 of ChatViewController.m. If you return from that function before that line, all is working correctly.
I've tried enabling all kind of Xcode 'magic' to debug memory problems (zombie, address sanitizer, etc.) and even open a ticket to Apple (they say it's probably related to libPusher and they won't investigate further on third party libs).

Many thanks in advance,
Andrea
ibapremiumTEST.zip

[hamchapman]

I've been able to recreate this locally and am investigating further

[hamchapman]

It looks like it's something to do with what's inside the handleWithBlock block. I tried commenting out everything inside the block and the issue doesn't present itself anymore. I'll keep digging

[hamchapman]

If I comment out the first call to bindToEventNamed and then inside the second calls handleWithBlock, comment out this code:

//        for (item in self.notifyList)
//        {
//            if([channelEvent.data objectForKey:@"id"])
//            {
//                if([item.ID isEqualToString:[channelEvent.data objectForKey:@"id"]])
//                {
//                    if(item.statusId != READ)
//                    {
//                        item.statusId = READ;
//                        refreshNeeded = true;
//                    }
//                }
//            }
//        }
//        if(refreshNeeded)
//            [self refreshChatView];

Then the issue doesn't present itself. Adding any of that code back in causes the issue to return

[hamchapman]

Similarly, if I uncomment the first call to bindToEventNamed and comment out this code inside its block:

//        NSString* strURL = [NSString stringWithFormat:PUSHER_GET_MSG_URL, [channelEvent.data objectForKey:@"id"]];
//#if false
//        NSURLRequest *site_request = [NSURLRequest requestWithURL:[NSURL URLWithString:strURL]
//                                                      cachePolicy:NSURLRequestUseProtocolCachePolicy
//                                                  timeoutInterval:10.0];
//        
//        self.downloadedData = @"";
//        self.site_connection = [[NSURLConnection alloc] initWithRequest:site_request delegate:self];
//#else
//        HTTP *http = [[HTTP alloc] init];
//        [http get:strURL withHandle:^(NSString *dataStr) {
//            [self decodeResponse:dataStr triggerEvent:NO];
//        }];
//#endif

Then the issue doesn't appear.

I don't think this is related to libPusher, so will close this for now. If you think otherwise though, then please reopen and we can investigate further. Thanks!

[sfaragnaus]

I'm reopening this just cause I've found some similarities that could worth investigating. See Issues #144 and #143. In both of them there are strange problems with bindToEventNamed: and handleWithBlock. It seems than neither of the two have a real solution to the issue besides moving code around. They referenced libPusher 1.5 in which the error was apparent by SIGSEGV, could it be that in 1.6 (the one I'm using) this do not lead to SIGSEGV but has some other (possibly memory related) subtle behaviour like the one I'm experiencing? That is: some bug lurking somewhere that has not been completely solved yet? I'm investigating further... this is getting interesting!

[sfaragnaus]

Hi Hamiltom, Luke,
sorry to bother, can you please reopen issue #209? I've added a comment
maybe it work investigating further.

Many thanks,
Andrea

On Thu, Apr 7, 2016 at 1:23 PM, Hamilton Chapman notifications@github.com
wrote:

Closed #209 #209.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#209 (comment)

[sfaragnaus]

After some further investigation, I noticed that the code inside the handleWithBlock: is never executed, as you can easily check by adding a couple of breakpoint inside the parenthesis. So it's not the added code itself to produce the issue, rather something that happens inside the bindToEventNamed: function when handleWithBlock statement is not empty. It sound a little voodoo, but I'l keep digging...

[sfaragnaus]

I'm in contact with Apple DTS to debug this issue and they say if any libpusher main developer would like to debug this with someone from Apple. Would you be so kind to investigate further with them? I can provide the follow up number that track this issue as you can see in Apple response here below:

"I had a conversation with Apple's DTS management team and here is our feedback about your request:

1. Since the issue is directly triggered by a libPusher, they are at the best position to begin the investigation. We hence suggest you to ask help from them. It is our policy that DTS only supports Apple products.
2. If the author of libPusher does the invesgitation and concludes that the issue is about us, please ask them to contact us. The reason we need to work with them is because they know better how their code triggers the issue. And we would again ask them to provide a focused sample as well.
3. If you believe the issue is related to our auto layout system, we would prefer to see a case that can reproduce the issue without third-party code.

Hopefully this makes sense to you."

Many thanks

[nickjf89-zz]

Hi,

I am investigating this now and will come back to you shortly.

Thanks

[nickjf89-zz]

Hi,

I've tried all morning to resolve some code signing issues that were present in the project you attached originally, but with no success.

Could you please attach a current version?

Thanks.

[sfaragnaus]

Hi Nick, sry for the inconvenient. Please find the attached project, it is working for me running on simulator, I advise to use that. If you need to run on a real device you could either provide your own provisioning profile and click on 'fix issue' on the General property tab. If you feel it would be helpful, I can provide my skype credentials in order to set up a voice meeting, it could be easier to debug together.
TESTpusherLoginCrash.zip

Many thanks

[nickjf89-zz]

Hi,

For some reason, I still cannot code sign your project with any of my own profiles; even wildcards.

I don't have this issue with other projects oddly. I'm not sure what the problem could be!

I'm happy to keep trying to debug this issue for you, so any suggestions you may have would be great!

Please note I'm using Xcode 8 with automatic signing.

Thanks

[sfaragnaus]

Hmm that's odd. I'll upgrade to Xcode 8 (I'm using 7.3 right now) in order to see if I can replicate the code sign issue and I'll come back to you.
Thanks

[sfaragnaus]

Hi Nick, I've reproduced the code sign issue, it seems that this is broken only on Xcode 8. PLease find the attached modified project, it should work now (at least works here for me). I've changed a couple of things, most importantly you need to select your team as per screenshot. Let me know if it builds now.

ibapremiumTESTpusherLoginCrash - TO BE DELETED.zip

thanks

[sfaragnaus]

Hi Nick, did you have the chance to try the last project i sent you in the previous post? It should build now in Xcode 8.

thx

[nickjf89-zz]

Hi,

I'm afraid I was still unable to build this project due to code-signing issues.

[sfaragnaus]

Oh this is unfortunate. I'm currently able to build on xcode 8 so it's weird. Please let me know if you are available for a meeting on skype so we can perhaps fix this together. thx

[sfaragnaus]

or could you pls post the exact and complete error that codesign is writing in your console?

[nickjf89-zz]

Hi,

I am seeing this error:

Command /usr/bin/codesign failed with exit code 1

I have tried using my own profiles, which work on other projects.

[sfaragnaus]

Hmmmm.. and nothing else? It usually write something more specific like 'provisioning profiel not found' or 'assets bundle error'. However, pls try the following:

• clean the project and close Xcode
• open terminal and digit:
  xattr -rc your_project_directory
  cd /Users/YOUR-USER-NAME/Library/Developer/Xcode/DerivedData
  rm -rf ibapremium*
• reopen xcode and build

Try also to select an actual device instead of a simulator, this sometimes makes the difference.

many thx

[nickjf89-zz]

Hi,

@hamchapman managed to get this to build through various workarounds, so I'll be looking at it today and tomorrow, and I'll get back to you with an update as soon as I can.

Thanks

[sfaragnaus]

Hi Nick,
did you or @hamchapman manage to find anything about this issue? As I mentioned earlier, Apple would be keen to debug this with you in order to find the culprit, but they ask for you to contact them...

Many thanks

[hamchapman]

Hi @sfaragnaus, unfortunately we didn't We weren't able to figure out what was going on.

I'm more than happy to get in touch with Apple. Do you have a contact that I should reach out to? You can email me at hamilton@pusher.com if that's easier.

Thanks!