Parse-sdk-ios-osx: 1.14.2: "Cannot register subclasses in a bundle that hasn't been loaded!"
Just to report a crashlytics event that has occurred for a few users on a build that uses the Parse 1.14.2 SDK. It's crashing in [PFObjectSubclassingController _registerSubclassesInBundle:] at the assertion that bundle.loaded is true. I can see from the report that it is being called from the NSBundleDidLoadNotification notification handler. There must be some inconsistency between that handler being called and the loaded property of the bundle being passed into the notification.
jmfieldman
All 112 comments
same crash on ios10
tantom
on 30 Aug 2016
Is this related to https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1021?
postmechanical
on 9 Sep 2016
Getting the same, iOS 10 only
Fatal Exception: NSInternalInconsistencyException
0 CoreFoundation 0x181a67eb0 __exceptionPreprocess
1 libobjc.A.dylib 0x1810604a8 objc_exception_throw
2 CoreFoundation 0x181a67df8 -[NSException initWithCoder:]
3 Parse 0x1006ec0f4 -[PFObjectSubclassingController _registerSubclassesInBundle:] (PFObjectSubclassingController.m:344)
4 Parse 0x1006eabe4 __63-[PFObjectSubclassingController scanForUnregisteredSubclasses:]_block_invoke (PFObjectSubclassingController.m:131)
5 Foundation 0x1823dd58c -[__NSObserver _doit:]
6 CoreFoundation 0x181a0424c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__
7 CoreFoundation 0x181a03950 _CFXRegistrationPost
8 CoreFoundation 0x181a036cc ___CFXNotificationPost_block_invoke
9 CoreFoundation 0x181a707bc -[_CFXNotificationRegistrar find:object:observer:enumerator:]
10 CoreFoundation 0x18194732c _CFXNotificationPost
11 Foundation 0x182435c94 -[NSBundle loadAndReturnError:]
12 UIAccessibility 0x18df302a4 -[NSBundleAccessibility loadAndReturnError:]
13 UIAccessibility 0x18df319ec +[UIAccessibilityLoader __loadActualAccessibilityBundle:didLoadCallback:loadSubbundles:]
14 UIAccessibility 0x18df31180 +[UIAccessibilityLoader _loadAXBundleForBundle:didLoadCallback:forceLoad:loadSubbundles:loadAllAccessibilityInfo:]
15 UIAccessibility 0x18df301c0 __70-[NSBundle(UIAccessibilityLoader) _loadAXBundleForBundleOffMainThread]_block_invoke
16 UIAccessibility 0x18df31130 +[UIAccessibilityLoader _loadAXBundleForBundle:didLoadCallback:forceLoad:loadSubbundles:loadAllAccessibilityInfo:]
17 UIAccessibility 0x18df2ff30 -[NSBundle(UIAccessibilityLoader) _loadAXBundleForBundleOffMainThread]
18 UIAccessibility 0x18df30378 __44-[NSBundleAccessibility loadAndReturnError:]_block_invoke_2
19 libdispatch.dylib 0x1814b1058 _dispatch_call_block_and_release
20 libdispatch.dylib 0x1814b1018 _dispatch_client_callout
21 libdispatch.dylib 0x1814c2e84 _dispatch_queue_serial_drain
22 libdispatch.dylib 0x1814b4808 _dispatch_queue_invoke
23 libdispatch.dylib 0x1814c3380 _dispatch_queue_override_invoke
24 libdispatch.dylib 0x1814c4d1c _dispatch_root_queue_drain
25 libdispatch.dylib 0x1814c4a7c _dispatch_worker_thread3
26 libsystem_pthread.dylib 0x1816bb3f8 _pthread_wqthread
27 libsystem_pthread.dylib 0x1816baef0 start_wqthread
aprato
on 14 Sep 2016
I just got a report of the same crash. The user is on iOS 10 and my app was compiled against the iOS 9 SDK.
bryanbartow
on 18 Sep 2016
Hi I'm getting this error also. 98% of crashes reported on iOS10. 2% on 9.
aylesm
on 19 Sep 2016
+1
iDurian
on 21 Sep 2016
Same crash reported in my app, only on iOS 10. Anyone have some sugestion?
leonardo-ferreira07
on 21 Sep 2016
@nlutsenko Bump. This is affecting a bunch of users for us now: http://crashes.to/s/eed9b65fd5c
ldiqual
on 1 Oct 2016
Yeah! It's a real problem! Does anybody have a solution?
lexin
on 10 Oct 2016
Here is our report: http://crashes.to/s/05649b8223f
funnel20
on 14 Oct 2016
We're also seeing this. Just started with our last release yesterday, using 1.14.2. All of the crashes are on iOS 10. Haven't been able to reproduce locally, though.
jordanhaven
on 14 Oct 2016
Seeing this too. A ton of crashes. 98% on iOS 10.
alex-maltsev
on 14 Oct 2016
Also experiencing this issue. Any updates?
TimothyDavidW
on 19 Oct 2016
Also experiencing this, compiling against 9 and seeing only in iOS 10
ichibod
on 26 Oct 2016
It's also reported on the new iOS 10.1.0
funnel20
on 26 Oct 2016
Same problem here. :(
allanscofield
on 27 Oct 2016
The crash happens in method '_registerSubclassesInBundle:', which is called from the completion block of NSBundleDidLoadNotification in 'scanForUnregisteredSubclasses:' in line 131.
As the PFConsistencyAssert() on line 342 indicates in the crash reports, the bundle is not loaded.
Shouldn't the solution be to terminate this method (i.e. not continuing with crashing line 344) when the bundle is not loaded?
This might be related to https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/pull/981
funnel20
on 30 Oct 2016
Any solution?
MattiaConfalonieri
on 3 Nov 2016
I'm also seeing this in my crashlogs. I fix would be nice.
andreaslindahl
on 9 Nov 2016
Just a quick diagnosis of this crash: From looking at the code it seems the codebase makes the assumption that when NSBundleDidLoadNotification is signaled that the bundle calling the notification is fully loaded (thus the assertion on bundle.loading).
Someone would need to see the internals of NSBundle, but if you take a super-pedantic interpretation of the documentation:
"When a request is made to an NSBundle object for a class (classNamed: or principalClass), the bundle dynamically loads the executable code file that contains the class implementation and all other class definitions contained in the file. After the module is loaded, the bundle posts the NSBundleDidLoadNotification."
It only loads the implementation for the requested class, and just the definition of the other classes -- not a complete load (thus loaded is still false). The notification handler needs to read the NSLoadedClasses key of the notification to see which classes were loaded. In other words, the notification means "Hey I loaded these particular classes" not "Hey I loaded the whole bundle"
The crash could probably be averted if [bundle load]; is added just above the assertion in _registerSubclassesInBundle:. That would make sure to complete a partial load before the rest of the function executes.
jmfieldman
on 9 Nov 2016
Thanks @jmfieldman for looking into this problem. I'll try to use your fix in future app update to see if it solves the issue.
zvonicek
on 10 Nov 2016
Is there an estimate when this update will take place?
I don't see any activity in the iOS/macOS repository over the last 3 months.
funnel20
on 10 Nov 2016
We have implemented the proposal from @jmfieldman:
- (void)_registerSubclassesInBundle:(NSBundle *)bundle {
// Prevent crash by loading the bundle if it's not loaded yet (see: https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1006 ):
if (!bundle.loaded) {
[bundle load];
}
PFConsistencyAssert(bundle.loaded, @"Cannot register subclasses in a bundle that hasn't been loaded!");
And recompiled the framework.
We'll release an app update with this framework today to TestFlight.
funnel20
on 11 Nov 2016
The above changes are live in our App Store version now, and the same crash is still happening.
So the [bundle load] call doesn't help.
Maybe loading of the bundle takes time, and isn't completed yet when the crashing line of code is executed.
So maybe the method should continue async in some way, after bundle.loaded is finally true.
Any suggestions (e.g. while loop)?
funnel20
on 17 Nov 2016
Damn, guess I'll withdraw my pull request :(
I wonder if it's happening with the same bundle each time (i.e. there is just one system bundle that's the culprit) that wouldn't have anything to do with subclassing anyway? Some system bundle that can't load properly?
Maybe add bundle.bundleIdentifier to the PFConsistencyAssert to see which one is failing? If it's the same one every time there might a super-dirty hack in just ignoring that.
The truth is, you could even just whitelist only the bundle identifiers that you know have Parse subclasses -- not a sustainable solution but at least might make your release stable from the perspective of this crash.
jmfieldman
on 17 Nov 2016
I wish it worked out better.
Great idea to add the bundle ID. I'll add that, recompile and submit an update to Apple.
To be honest, I have no clue what the purpose is of the bundle loading event(s) in Parse SDK.
As far as I know, all required data is available in the app's main bundle.
Or do I miss something?
Why is it necessary, or can we eliminate it at all?
funnel20
on 17 Nov 2016
I think if you have an Obj-C project, and your frameworks are statically linked then you're right and they're all in the main bundle. However, some Swift projects (like the one I originally submitted this issue for) split their code into dynamic frameworks that are loaded as bundles (and could conceivably contain PFObject subclasses).
jmfieldman
on 17 Nov 2016
I don't understand the details, but I do understand that this is required.
Do you have any other suggestions to print in the Assert, which might help to tackle this issue?
funnel20
on 17 Nov 2016
Not really; will be interesting to see if it's just one bundle that this happens to. Other things you can try:
a) remove the assertion completely
b) if bundle.loaded == false: return w/o doing anything (don't assert)
jmfieldman
on 17 Nov 2016
First test will be with this:
- (void)_registerSubclassesInBundle:(NSBundle *)bundle {
// Prevent crash by loading the bundle if it's not loaded yet (see: https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1006 ):
NSError *error = nil;
if (!bundle.loaded) {
[bundle loadAndReturnError:&error];
}
PFConsistencyAssert(bundle.loaded, @"Cannot register subclasses in a bundle that hasn't been loaded! Bundle ID = %@, Error = %@", bundle.bundleIdentifier, error);
Instead of [bundle load] I have used [bundle loadAndReturnError:&error]. Hopefully this will print a useful error in the Assert, as well as the bundle.bundleIdentifier.
funnel20
on 17 Nov 2016
Awesome -- interested in seeing what comes up!
jmfieldman
on 17 Nov 2016
Also seeing this with ~10% of users so far. All from iOS 10.
From Podfile.lock:
- Parse (1.14.2):
- Bolts/Tasks (~> 1.8)
ckbhodge
on 22 Nov 2016
We have submitted our app update with the recompiled Framework to Apple.
Expected to go live within 24 hours....
funnel20
on 23 Nov 2016
I have some very bad news: we can't learn from the extra debug info, because...
...it doesn't crash anymore 馃憤
The update is live for over 48 hours and has had more than 40k launches.
Our previous versions crashed 10-20 times a day, even the 2 days after release.
There wasn't a public iOS update released this week (10.1.1 is from November 9).
The only explanation that I have why this code might work is that loadAndReturnError: is somehow asynchronous, so that it waits until the bundle is loaded, before continuing with the line with PFConsistencyAssert().
But of course we need more test data to finally conclude that this work-around fixes the crash.
So it would be nice if other devs can also try this piece of code in Production apps and share results.
To prevent you the extra work of recompiling the Parse framework, I can share my custom version.
Newbie question: Is it possible to host that file somewhere on GitHub, or should I put it somewhere else?
UPDATE November 28: Still no crashes reported.
funnel20
on 26 Nov 2016
@funnel20 - that's good news. would you mind sharing your compiled version somewhere so we can quickly try your fix without learning how to compile Parse? thx, Billy.
billylo1
on 4 Dec 2016
Our recompiled Parse.framework is no longer available since there is a better solution by @flovilmart.
Please note that we only changed the code above, not the version in the Info.plist. So it's still at 1.14.2.
Please treat this as a beta version, we take no responsibility whatsoever by using this version in your production code. If you don't want to take a risk, either wait for the official update or recompile yourself.
funnel20
on 5 Dec 2016
When this is available in an official release?
MattiaConfalonieri
on 5 Dec 2016
@funnel20 did you open a pull request?
flovilmart
on 5 Dec 2016
@flovilmart No, because we should get confidence that this code change indeed fixes the crash for other users as well.
Unfortunately no one responded whether they are going to use the code change or the custom-compiled Framework that I uploaded.
@Community: Who is going to try the proposed solution, so we know it will solve this issue permanently?
funnel20
on 12 Dec 2016
@funnel20 I built the framework with your fix and sent it to my app team last week, but need to check if they've integrated it yet. I'll report back when I find out.
jordanhaven
on 12 Dec 2016
My users at Sidekick (navigation+dashcam+alerting app) have picked up this fix and I have not seen a new crash with the same signature.
Thumbs up from my viewpoint. Thanks to all of you.
billylo1
on 12 Dec 2016
Please make a PR for this fix, the situation is very annoying.
MattiaConfalonieri
on 16 Dec 2016
Just submitted a build of my app including @funnel20 precompiled framework, which exhibited no issues during internal testing. I'll report back once it's approved and in the wild.
bryanbartow
on 24 Dec 2016
@nlutsenko When are you going to fix this issue. It's terrible.
ArtemGoryunov
on 30 Dec 2016
I'm using the fix proposed by @funnel20 in production since a month. Thousands of installations and no crashes. It's working like a charm in my case. You can find my fork with the fix here: https://github.com/sirioz/Parse-SDK-iOS-OSX
sirioz
on 30 Dec 2016
@sirioz / @funnel20 please open a PR and I'll craft a release.
flovilmart
on 3 Jan 2017
My app build just got approved by Apple. I'll report back in a couple days.
bryanbartow
on 4 Jan 2017
We also submitted today, I'll report back as the solution we put up is slightly different from what was suggested:
https://github.com/AmpMe/Parse-SDK-iOS-OSX/commit/4cd853c9b3dc05cc44ef2c8d0a261f77729af92f
flovilmart
on 4 Jan 2017
We released our build with @funnel20 fix about two weeks ago, and no crashes in that version.
If no one else gets around to making a PR, I guess I can do one?
jordanhaven
on 4 Jan 2017
I'm not convinced force loading is the solution, that seems hackish and doesn't either follow the checks that are made on the other loaded bundles.
flovilmart
on 4 Jan 2017
excited to hear from people who said they would report back. has this been released been cut with the fix?
myusuf3
on 5 Jan 2017
Just a little over 24 hours in and no crashes. I was typically seeing 1 or 2 per 24 hours. So far so good. Will report back in another day or two.
bryanbartow
on 5 Jan 2017
@bryanbartow are you using the fix above?
myusuf3
on 5 Jan 2017
@jordanhaven can you release a framework bundle on your branch with the included fix? I am using the framework and there isn't a way to add the edit you pushed.
myusuf3
on 5 Jan 2017
@flovilmart Do you have an alternative in mind?
postmechanical
on 5 Jan 2017
@postmechanical see: https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1006#issuecomment-270283592
flovilmart
on 5 Jan 2017
@myusuf3 We used @funnel20 precompiled framework mentioned in this comment.
bryanbartow
on 6 Jan 2017
Update: Approximately 48 hours in and no crashes.
bryanbartow
on 6 Jan 2017
This looks like the same as https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1068
levigroker
on 6 Jan 2017
Update: Almost a week in and not a single crash.
bryanbartow
on 10 Jan 2017
I don't see any crashes either with the alternate fix
flovilmart
on 10 Jan 2017
@flovilmart what alternate fix are you using?
tarekskr
on 10 Jan 2017
flovilmart
on 10 Jan 2017
@flovilmart Are you going to create a new release based on your solution or are we still debating which approach is better?
bryanbartow
on 10 Jan 2017
@bryanbartow I 'prefer' the approach I took as safer, as it also guarantees the SDK won't 'force load' a bundle that may be problematic. I'm open to suggestions on that one, I'll open a PR.
flovilmart
on 10 Jan 2017
Personally, I like the look of the approach @flovilmart mentions. It seems far more robust to me.
levigroker
on 10 Jan 2017
Now that I've looked at both, I agree with @levigroker. @flovilmart solution seems safer.
bryanbartow
on 10 Jan 2017
+1 on @flovilmart
brianyyz
on 10 Jan 2017
If @flovilmart wants to open a PR for his, I'm happy to close the other one :)
jordanhaven
on 11 Jan 2017
PR is open.
flovilmart
on 11 Jan 2017
Great work!
I'm glad that you found a robust solution, instead of my unexplainable work-around that I stumbled on accidentally.
Exactly the reason why I didn't want to create a PR immediately, despite a lot of pushing from the impatient 馃槇
I have removed the link to my framework.
funnel20
on 11 Jan 2017
If anyone is using cocoa pods, it's trivial to point to the fix branch of our repo:
pod 'Parse', git: 'https://github.com/ampme/Parse-SDK-iOS-OSX', branch: 'fix-1006'
How can I create a release for iOS? I cloned the repo locally but in the master branch I can't find the fix.
mtrezza
on 13 Jan 2017
As @flovilmart wrote a post before, just replace in your pod file the pod'Parse', with pod 'Parse', git: 'https://github.com/ampme/Parse-SDK-iOS-OSX', branch: 'fix-1006'. And then run pod install. Thats all.
mmarshak
on 13 Jan 2017
I don't use CocoaPods, how can I compile the SDK manually in Xcode to create the Parse.framework?
Edit: Ok just found the compile instructions on https://github.com/ampme/Parse-SDK-iOS-OSX
mtrezza
on 13 Jan 2017
I'd like to include @flovilmart's fix in an upcoming release of my app. Any chance an official release can be made soon, or I should simply use the ampme branch?
bourquep
on 16 Jan 2017
I don't have commit access on this repo (yet), probably @nlutsenko, @richardjrossiii, @hramos could do something about it. I however have the ability to make official cocoa pods release IIRC.
flovilmart
on 16 Jan 2017
This is unacceptable that this hasn't been fixed in master. I will hold off on updating to 1.14.2.
sirnacnud
on 5 Feb 2017
It's great that we have a fix merged @hramos. Thank you. When can we expect a new cocoapod version with this fix?
levigroker
on 7 Feb 2017
I renew the question, when it will be available in the cocoapod version?
MattiaConfalonieri
on 14 Feb 2017
@flovilmart can you help with the CocoaPods release?
hramos
on 14 Feb 2017
I should have access, I'll check it out
flovilmart
on 14 Feb 2017
@flovilmart Thanks for making the official 1.14.3 release.
funnel20
on 21 Feb 2017
@nlutsenko @hramos i still can't publish the pod :/
flovilmart
on 21 Feb 2017
@flovilmart https://cocoapods.org/?q=parse still shows 1.14.2, what is the issue publishing the pod?
mforest
on 24 Feb 2017
I don't have the credentials to add the pod
flovilmart
on 24 Feb 2017
Thanks the parse contributors for fixing this long outstanding problem.
I spend one hour debugging on this problem. I like to share this with fellow Parse users.
I have upgraded from 1.13.0 to 1.14.3 and using automatic class registering. I did everything correct except that I use Match as UITableViewController variable. This will cause the app to crash on launch. It seems that the storyboard was loaded during launch and therefore the Match was initialised. I solve this problem by using "lazy" variable instead of normal variable.
// don't use this
var match = Match()
// use this so that the match is not initialised too early.
lazy var match = Match()
Full details as follows...
class Match : PFObject, PFSubclassing {
...
}
I define match as a UITableViewController class variable.
class ScoreSheetViewController: UITableViewController,
PFLogInViewControllerDelegate,
{
// Match selection
var match = Match()
...
}
The app crashed on launch with these error message.
YYYY-MM-DD 21:02:18.174 MyApp[27054:1067852] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'The class MyApp.Match must be registered with registerSubclass before using Parse.'
*** First throw call stack:
(
0 CoreFoundation 0x0000000112dd7d4b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00000001124d021e objc_exception_throw + 48
2 CoreFoundation 0x0000000112e412b5 +[NSException raise:format:] + 197
3 MyApp 0x000000010fd822a9 -[PFObject init] + 215
4 MyApp 0x000000010fc69817 _TFC13MyApp5MatchcfT_S0_ + 1319
5 MyApp 0x000000010fc698ac _TFC13MyApp5MatchCfT_S0_ + 44
6 MyApp 0x000000010fc5c30e _TFC13MyApp24ScoreSheetViewControllercfT5coderCSo7NSCoder_GSqS0__ + 46
7 MyApp 0x000000010fc5c8dd _TToFC13MyApp24ScoreSheetViewControllercfT5coderCSo7NSCoder_GSqS0__ + 45
8 UIKit 0x000000011360a043 -[UIClassSwapper initWithCoder:] + 240
9 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
10 UIKit 0x00000001137fe357 UINibDecoderDecodeObjectForValue + 1122
11 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
12 UIKit 0x0000000113398f0e -[UIViewController initWithCoder:] + 1441
13 UIKit 0x00000001133c82e2 -[UINavigationController initWithCoder:] + 66
14 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
15 UIKit 0x00000001137fe357 UINibDecoderDecodeObjectForValue + 1122
16 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
17 UIKit 0x0000000113398f0e -[UIViewController initWithCoder:] + 1441
18 UIKit 0x00000001133f0bf5 -[UITabBarController initWithCoder:] + 66
19 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
20 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
21 UIKit 0x0000000113398b4f -[UIViewController initWithCoder:] + 482
22 UIKit 0x00000001133c82e2 -[UINavigationController initWithCoder:] + 66
23 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
24 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
25 UIKit 0x00000001132fa706 -[UINavigationBar initWithCoder:] + 389
26 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
27 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
28 UIKit 0x00000001132f08b7 -[UINavigationItem initWithCoder:] + 815
29 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
30 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
31 UIKit 0x0000000113398b26 -[UIViewController initWithCoder:] + 441
32 UIKit 0x000000011361cb2b -[UITableViewController initWithCoder:] + 60
33 MyApp 0x000000010fd485c3 -[PFQueryTableViewController initWithCoder:] + 40
34 MyApp 0x000000010fc7ba65 _TFC13MyApp18TeamViewControllercfT5coderCSo7NSCoder_GSqS0__ + 645
35 MyApp 0x000000010fc7bcbd _TToFC13MyApp18TeamViewControllercfT5coderCSo7NSCoder_GSqS0__ + 45
36 UIKit 0x000000011360a043 -[UIClassSwapper initWithCoder:] + 240
37 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
38 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
39 UIKit 0x0000000113609d14 -[UIRuntimeConnection initWithCoder:] + 178
40 UIKit 0x000000011360a44d -[UIRuntimeEventConnection initWithCoder:] + 60
41 UIKit 0x00000001137fe1a1 UINibDecoderDecodeObjectForValue + 684
42 UIKit 0x00000001137fe357 UINibDecoderDecodeObjectForValue + 1122
43 UIKit 0x00000001137fdeee -[UINibDecoder decodeObjectForKey:] + 98
44 UIKit 0x0000000113608eb8 -[UINib instantiateWithOwner:options:] + 1249
45 UIKit 0x00000001139c8f7b -[UIStoryboard instantiateViewControllerWithIdentifier:] + 181
46 UIKit 0x00000001131fb47d -[UIApplication _loadMainStoryboardFileNamed:bundle:] + 111
47 UIKit 0x00000001131fb947 -[UIApplication _loadMainInterfaceFile] + 260
48 UIKit 0x00000001131f9fa8 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1406
49 UIKit 0x00000001131f726d -[UIApplication workspaceDidEndTransaction:] + 188
50 FrontBoardServices 0x0000000118e796cb __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 24
51 FrontBoardServices 0x0000000118e79544 -[FBSSerialQueue _performNext] + 189
52 FrontBoardServices 0x0000000118e798cd -[FBSSerialQueue _performNextFromRunLoopSource] + 45
53 CoreFoundation 0x0000000112d7c761 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
54 CoreFoundation 0x0000000112d6198c __CFRunLoopDoSources0 + 556
55 CoreFoundation 0x0000000112d60e76 __CFRunLoopRun + 918
56 CoreFoundation 0x0000000112d60884 CFRunLoopRunSpecific + 420
57 UIKit 0x00000001131f5aea -[UIApplication _run] + 434
58 UIKit 0x00000001131fbc68 UIApplicationMain + 159
59 MyApp 0x000000010fca4cff main + 111
60 libdyld.dylib 0x0000000115adb68d start + 1
61 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
nebitrams
on 24 Feb 2017
That's a different crash, nonetheless, a good reminder that your storyboard maybe evaluated before applicationDidFinishLaunching is called !
flovilmart
on 24 Feb 2017
@hramos @nlutsenko I saw that you maintain the pod before, could you publish the new release v1.14.3 on https://cocoapods.org/?q=parse sometime soon. This version resolves a long standing issue and we don't want to explicitly include parse.sdk into our project. Cocoapods resolves dependencies for us.
Thanks!
mforest
on 24 Feb 2017
Please update in pod with v1.14.3
skparticles
on 3 Mar 2017
+1
beonhome
on 3 Mar 2017
Sad to say there's a crash related to the https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/pull/1090 merge which is intended to fix this issue. Further comments in the merge request.
levigroker
on 8 Mar 2017
I can confirm that we have the same crash reported in our app, since we implemented 1.14.3:
PFObjectSubclassingController.m line 335
-[PFObjectSubclassingController _registerSubclassesInLoadedBundle:]
Fortunately the occurrence of the new crash is significantly lower than the original crash.
There is still the old suggestion with loadAndReturnError::
- (void)_registerSubclassesInBundle:(NSBundle *)bundle {
// Prevent crash by loading the bundle if it's not loaded yet (see: https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1006 ):
NSError *error = nil;
if (!bundle.loaded) {
[bundle loadAndReturnError:&error];
}
PFConsistencyAssert(bundle.loaded, @"Cannot register subclasses in a bundle that hasn't been loaded! Bundle ID = %@, Error = %@", bundle.bundleIdentifier, error);
This is successfully tested in our production app for 3 months with 50K sessions per day, before we switched to version 1.14.3.
funnel20
on 8 Mar 2017
I've created https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/pull/1119 to avoid the bad selector issue.
levigroker
on 8 Mar 2017
I am sad to report crashes creep back for my app too... rolling back to @funnel20's fix...
billylo1
on 24 Mar 2017
We haven't seen a crash since it's been implemented. Do any of you have crash reports to share?
flovilmart
on 24 Mar 2017
This is from 1.14.2 (official)... Haven't picked up 1.14.3. Trying to bring stability back to the user base first. Hope this helps.
9
libobjc.A.dylib
objc_exception_throw + 34444
10
CoreFoundation
+[NSException raise:format:] + 1245436
11
Sidekick
-[PFObjectSubclassingController _registerSubclassesInBundle:] (PFObjectSubclassingController.m:342)
12
Sidekick
__63-[PFObjectSubclassingController scanForUnregisteredSubclasses:]_block_invoke (PFObjectSubclassingController.m:131)
13
Foundation
-[__NSObserver _doit:] + 35368
14
CoreFoundation
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 826124
billylo1
on 24 Mar 2017
The issue is fixed on master, obviously it's crashing on 1.14.2 as it was initially reported
flovilmart
on 24 Mar 2017
My bad... I assumed that 1.14.3 is in the official pod update... should I be using Parse from https://github.com/ampme/Parse-SDK-iOS-OSX, branch fix-1006
until 1.14.3 is in cocoapods officially?
billylo1
on 24 Mar 2017
@flovilmart Thanks for following up on this issue. A number of us have been waiting for the update on cocoapods. Is there any reasons you can think of why the folks who maintained the pod in the past (Nikita Lutsenko, Grantland Chew, H茅ctor Ramos, Facebook, Inc.) don't update it with 1.14.3?
mforest
on 24 Mar 2017
There seems to be a trouble for transferring the credentials for releasing on cocoapods.
However not everything is blocked, you can use the 'git' reference in your podfile, specifying :tag '1.14.3'
flovilmart
on 24 Mar 2017
As indicated above, the official 1.14.3 (downloaded at https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases) will create a new crash:
PFObjectSubclassingController.m line 335
-[PFObjectSubclassingController _registerSubclassesInLoadedBundle:]
See crash report: http://crashes.to/s/10066b4be21
Since multiple members did successfully implement my solution in their production apps, I would request to revert the actual change to 1.14.3 and implement mine; the async loadAndReturnError::
- (void)_registerSubclassesInBundle:(NSBundle *)bundle {
// Prevent crash by loading the bundle if it's not loaded yet (see: https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/1006 ):
NSError *error = nil;
if (!bundle.loaded) {
[bundle loadAndReturnError:&error];
}
PFConsistencyAssert(bundle.loaded, @"Cannot register subclasses in a bundle that hasn't been loaded! Bundle ID = %@, Error = %@", bundle.bundleIdentifier, error);
This is successfully tested in our production app for 3 months with 50K sessions per day, before we switched to version 1.14.3.
funnel20
on 24 Mar 2017
It seems that the crash you're seeing is caused by the bundle not being a proper NSBundle* in which case, would also crash with your solution as you're accessing the .loaded property.
Without more context with your crash, it's hard to determine what the actual type of bundle is.
How many crashes / 10k sessions do you see?
flovilmart
on 24 Mar 2017
As mentioned earlier, I created #1119 to avoid the bad selector issue, as we too are getting this crash (of course).
levigroker
on 31 Mar 2017
Currently affecting ~20% of my users. 10,000 total users. I'm switching to fix #1006 and publishing tonight. Will report back!
jdleo
on 27 Jul 2017
@jdleo the SDK has been released for a while...
flovilmart
on 27 Jul 2017
@jdleo Can you elaborate with which version you see these tremendous amount of crashes?
We have 1.14.4 in production.
Here are the stats from the last 30 days with 250K monthly users:
[PFObjectSubclassingController _registerSubclassesInBundle:] not reported
[PFObjectSubclassingController _registerSubclassesInLoadedBundle:] reported 14 times
funnel20
on 30 Jul 2017
did anyone found any solution?
i've done with
`
NSError *error = nil;
if (!bundle.loaded)
{
[bundle loadAndReturnError:&error];
}
PFConsistencyAssert(bundle.loaded, @"Cannot register subclasses in an unloaded bundle: %@", bundle);`
tahirbinpasha
on 7 Jan 2019
A formal solution has been implemented in 1.14.3, that reduced the crashes significantly.
Meanwhile we are running on 1.17.1, and the issue has not been reported anymore.
Of course this issue might also have been related to iOS 11, which can be solved in iOS 12.
As Crashlytics deletes the data after 90 days, we can't check this anymore.
Which Parse version is the crash reported and on which iOS version?
funnel20
on 7 Jan 2019
A formal solution has been implemented in 1.14.3, that reduced the crashes significantly.
Meanwhile we are running on 1.17.1, and the issue has not been reported anymore.
Of course this issue might also have been related to iOS 11, which can be solved in iOS 12.
As Crashlytics deletes the data after 90 days, we can't check this anymore.Which Parse version is the crash reported and on which iOS version?
Device : iPhone 6s Plus
iOS Version : 12.1.2
Parse : 1.14.3
tahirbinpasha
on 7 Jan 2019
So it's not related to iOS.
Why are you still using old Parse version, and not the latest 1.17.1?
Upgrade and the issue is resolved.
funnel20
on 7 Jan 2019
I am using 1.17.2 and I am currently seeing this same issue.
kwilk83
on 29 Jan 2019
Related issues
HackShitUp
路
3Comments
talkaboutdesign
路
8Comments
mman
路
8Comments
kazukiotsuka
路
3Comments
josepfm
路
7Comments
Most helpful comment
I have some very bad news: we can't learn from the extra debug info, because...
...it doesn't crash anymore 馃憤
The update is live for over 48 hours and has had more than 40k launches.
Our previous versions crashed 10-20 times a day, even the 2 days after release.
There wasn't a public iOS update released this week (10.1.1 is from November 9).
The only explanation that I have why this code might work is that
loadAndReturnError:is somehow asynchronous, so that it waits until the bundle is loaded, before continuing with the line withPFConsistencyAssert().But of course we need more test data to finally conclude that this work-around fixes the crash.
So it would be nice if other devs can also try this piece of code in Production apps and share results.
To prevent you the extra work of recompiling the Parse framework, I can share my custom version.
Newbie question: Is it possible to host that file somewhere on GitHub, or should I put it somewhere else?
UPDATE November 28: Still no crashes reported.