Safely inspect bundles for classes

[flovilmart]

Fixes #1006

Makes sure we don't check classes in not loaded bundles.

[flovilmart]

@hramos @nlutsenko, we are kinda stuck here with that one. Could you review, advise?

[flovilmart]

Thanks @hramos !

[flovilmart]

@hramos I'll need the commit access to the repo as Cocoapods require the tag to be pushed before
I can send pod to trunk. Opening #1111

[hramos]

@flovilmart invited

[flovilmart]

Turns out I don't have access to the pods either ;/

!] You ([email protected]) are not allowed to push new versions for this pod. The owners of this pod are [email protected], [email protected], [email protected], and [email protected].

[levigroker]

Anyone have pod access to push out 1.14.3? Please?

[levigroker]

@flovilmart We manually put this change in our now-production app and are seeing a crash (unknown selector sent to instance). Specifically, it appears that _registerSubclassesInLoadedBundle: can be called with objects (NSString apparently) which are not NSBundle objects, and the loaded message is sent to an object which doesn't handle the selector. I'd guess this is coming from the NSBundleDidLoadNotification note.object but haven't verified that.

An obvious armor for this is to ensure the object is of the intended type in _registerSubclassesInLoadedBundle.

i.e. Change:

if (!bundle.loaded || !bundle.executablePath) {

to

if (![bundle isKindOfClass:NSBundle.class] || !bundle.loaded || !bundle.executablePath) {

(though it would be nice to understand why we're not getting NSBundle objects, this will prevent the crash).

Since 1.14.3 has yet to be released, this change (or similar) prior to release would be appreciated.

Cheers,

Levi

[flovilmart]

The changes have been merged to master, can you open a Pr with your suggestion and the fix?

[levigroker]

@flovilmart Cheers. Here's the pull: #1119