Issue when chaining BFTasks created from Swift

[flovilmart]

The test [result isKindOfClass:[BFTask class]] is failing sometimes when using tasks created from Swift.

The result of the test is undefined (know bug by apple)

[nlutsenko]

isKindOfClass: should continue to work, since when converted to Swift - BFTask might become a subclass of BFTask aka SwiftBFTask. Which is valid for isKindOfClass:

Any chance you can create a repro PR that showcases the bug?

[flovilmart]

What’s odd now is that with a clean test framework I can’t reproduce the bug… But it repro 100% of times with the current project I’m working on.

I’ll get you screenshots of the current behaviour

On Fri, Jul 31, 2015 at 1:35 PM, Nikita Lutsenko [email protected]
wrote:

isKindOfClass: should continue to work, since when converted to Swift - BFTask might become a subclass of BFTask aka SwiftBFTask. Which is valid for isKindOfClass:

Any chance you can create a repro PR that showcases the bug?

Reply to this email directly or view it on GitHub:
#111 (comment)

[flovilmart]

As you can see the current stack: BOOL isKindOfClass = NO, however, with the NSStringFromClass.. introspection it yields "BFTask"

[flovilmart]

@nlutsenko what do you think? strange, odd and hardly reproductible with another project...

[flovilmart]

BTW, it's with the Bolts framework from the lastest FacebookSDK release

[krusek]

#116 includes a repository with a task that doesn't chain properly. I know it's supposed to be an issue with swift, but this has the exact same symptoms, but without swift...maybe it's closer to the actual root issue?

Edit: and it can be fixed in the same way, using NSStringFromClass rather than isKindOfClass:

[nlutsenko]

Great. Many thanks guys for the repro. I'll take a look shortly and will update here.

[krusek]

Actually, I just tried @flovilmart 's fix and it doesn't fix my particular case. What I'd done is just compared the two NSStringFromClass, which fixes his issue, but adds problems with subclasses, but for some reason that branch doesn't fix my example.

[flovilmart]

That's getting even more interesting. Two related issues which don't fix the same way 🍿

On Sat, Aug 8, 2015 at 9:22 PM, Korben Rusek [email protected]
wrote:

Actually, I just tried @flovilmart 's fix and it doesn't fix my particular case. What I'd done is just compared the two NSStringFromClass, which fixes his issue, but adds problems with subclasses, but for some reason that branch doesn't fix my example.

Reply to this email directly or view it on GitHub:
#111 (comment)

[nlutsenko]

@krusek I've just ran the test on Xcode 6.4 with the project from https://github.com/krusek/Bolts-error
It actually succeeds...

Was there anything specific about your configuration?

[nlutsenko]

I take it back, I can see the issue right now...

[nlutsenko]

Oh, crazy! I am yet once again amazed by how this is implicit, though extremely fragile.

I figured why this happens for you @krusek, which could also be the reason behind the problem with @flovilmart case (haven't seen the source there, so can't confirm).

It's extremely non-obvious, but since you have a dynamic framework that links Bolts.framework via static code, the code from it will be included there. Then you link Bolts.framework to your unit testing target.
Since code for BFTask now is both statically linked to KRTaskUnzipper.framework (loaded dynamically) and to Unit Testing Bundle (also loaded dynamically), and the code is the same - there is no compiler error or warning, though these classes are actually different and referenced differently in runtime.

So one is created inside KRTaskUnzipper.framework, but actually used by code from Unit Testing Bundle - which tries to lookup that class in it's runtime (doesn't lookup in dynamic libraries, since it finds it locally), but can't find the same class, so the answer for isKindOfClass: is NO. :D

Does it make sense guys? It's tough to explain, but I can try some other way...

Fix: Remove linking with Bolts.framework from your unit testing bundle.
Just tested it locally and it works as expected - it continues on a proper task and the result is NSString instead of BFTask with NSString.
Step-by-step to fix the project by @krusek :

• Remove KRTaskUnzipperTests from link_with in Podfile
• Remove libPods.a from Link phase on KRTaskUnzipperTests
• Remove $(inherited) and -l"Bolts" from Other Linker Flags on KRTaskUnzipperTests
• Run the tests
• ???
• Profit

I would recommend setting up the Framework via Cocoapods actually, so if you want to use it in a project or write tests against it - you link Bolts.framework only with a single target automatically and don't need to do the fix mentioned above. (we have this done in https://github.com/ParsePlatform/ParseUI-iOS)

Let me know if this helps, guys...

[flovilmart]

Awesome! Thanks for the fix!

I guess that will happen a lot with dynamic libs now that use libs.

If using Carthage and building/testing a framework (that will be distributed via Carthage), should I put my frameworks in framework search path in every case and let the automatic linking do it's magic?

On Sun, Aug 9, 2015 at 3:21 AM, Nikita Lutsenko [email protected]
wrote:

I take it back, I can see the issue right now...

Reply to this email directly or view it on GitHub:
#111 (comment)

[krusek]

it worked, thanks! my actual project has lots of BFTasks created and working properly (and some more pods), odd that only this snippet was borked (and could be pulled out into a separate/standalone project still being borked).

[nlutsenko]

@flovilmart - that works, yup. Another solution would be 'use_frameworks!' flag via Covoapods.

Thanks for raising this guys, and glad I could help.

[flovilmart]

Thanks @nlutsenko!

[flovilmart]

@nlutsenko

For me the resolution si not quite the same.

My project is a Swift framework.

I had Linking + Copy Files ( to Frameworks) for my dependencies (Bolts, Stripe and Realm)

When I removed Bolts from the linking and put it to auto linking the compiler could not build the framework as Bolts is no a dylib.

My solution was:

1. Remove the Deps. from Copy Bundle Resources
2. Remove dynamic libs from linking
3. Keep bolts linking in the framework AND the tests target
4. Keep the copy files to Frameworks to the tests bundles
5. Profit

So for my case, the resolution is also related to the build configuration, linking and embedding but solves differently!
Cheers!

F.