search

firebase / firebase-ios-sdk

Firebase SDK for Apple App Development
https://firebase.google.com
Apache License 2.0
5.67k stars 1.49k forks source link

Crash in -[TAGHitStore addPendingEvent:] #2465

Closed ffittschen closed 4 years ago

ffittschen commented 5 years ago

[REQUIRED] Step 2: Describe your environment

[REQUIRED] Step 3: Describe the problem

We are observing a crash happening in -[TAGHitStore addPendingEvent:].

Steps to reproduce:

We are not able to reproduce it yet.

Crashlog:

Fatal Exception: NSInvalidArgumentException
0  CoreFoundation                 0x22f239eb8 __exceptionPreprocess
1  libobjc.A.dylib                0x22e433f18 objc_exception_throw
2  CoreFoundation                 0x22f14ef10 -[NSOrderedSet initWithSet:copyItems:]
3  CoreFoundation                 0x22f23f924 ___forwarding___
4  CoreFoundation                 0x22f2416f0 _CF_forwarding_prep_0
5  Foundation                     0x22fcc744c _encodeObject
6  Foundation                     0x22fbd88bc -[NSKeyedArchiver _encodeArrayOfObjects:forKey:]
7  Foundation                     0x22fc0639c -[NSDictionary(NSDictionary) encodeWithCoder:]
8  Foundation                     0x22fcc744c _encodeObject
9  Foundation                     0x22fc27e00 +[NSKeyedArchiver archivedDataWithRootObject:]
10 <Redacted>                     0x100a62a80 -[TAGHitStore addPendingEvent:]
11 <Redacted>                     0x100a53e30 __29-[TAGContainer processEvent:]_block_invoke
12 libdispatch.dylib              0x22ec3bb9c _dispatch_call_block_and_release
13 libdispatch.dylib              0x22ec3d134 _dispatch_client_callout
14 libdispatch.dylib              0x22ec4464c _dispatch_lane_serial_drain
15 libdispatch.dylib              0x22ec45194 _dispatch_lane_invoke
16 libdispatch.dylib              0x22ec4d480 _dispatch_workloop_worker_thread
17 libsystem_pthread.dylib        0x22ee3eb20 _pthread_wqthread
18 libsystem_pthread.dylib        0x22ee44dd4 start_wqthread
paulb777 commented 5 years ago

Internally reported at b/127275684

ffittschen commented 5 years ago

Is there any update on this issue? We still see quite a lot of crashes due to this problem.

ffittschen commented 5 years ago

@paulb777 Is there an update to this issue?

allenktv commented 5 years ago

Hi @ffittschen , Are you using Swift or Obj-c for your app when using this? Are you using optionals or Swift enums/closures by any chance?

ffittschen commented 5 years ago

Hi @allenktv, we are using GTM in a Swift app and therefore we also use optionals, enums and closures. However, we have a protocol TrackableValue to constrain the parameter types we send with Firebase Analytics using a small wrapper func logEvent(_ key: String, parameters: [String: TrackableValue]) to the following String, Bool, Int, UInt64, Float, Double.

allenktv commented 5 years ago

Hi @ffittschen, I see, thank you for responding. We cannot seem to reproduce it on our end and I do not believe this has been reported elsewhere. What percentage of your users are experiencing this and how often are you seeing these crashes?

allenktv commented 5 years ago

I believe we can close this issue for now due to inactivity.

surajthomask commented 5 years ago

@allenktv We are facing this issue in our production app. We can't reproduce this as well, but has been occurring 30 times for 24 users in last 7 days. Below is the resolved pod dependencies for firebase stack.

Below given is the stacktrace for the crash

Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0x20aaea98c exceptionPreprocess 1 libobjc.A.dylib 0x209cc39f8 objc_exception_throw 2 CoreFoundation 0x20aa071c8 -[NSOrderedSet initWithSet:copyItems:] 3 CoreFoundation 0x20aaf01d4 __forwarding 4 CoreFoundation 0x20aaf1e6c _CF_forwarding_prep_0 5 Foundation 0x20b53b808 _encodeObject 6 Foundation 0x20b456c90 -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] 7 Foundation 0x20b483398 -[NSDictionary(NSDictionary) encodeWithCoder:] 8 Foundation 0x20b53b808 _encodeObject 9 Foundation 0x20b4a3e20 +[NSKeyedArchiver archivedDataWithRootObject:] 10 APPNAME 0x10142fae0 -[TAGHitStore addPendingEvent:] 11 APPNAME 0x10142102c __29-[TAGContainer processEvent:]_block_invoke 12 libdispatch.dylib 0x20a528a38 _dispatch_call_block_and_release 13 libdispatch.dylib 0x20a5297d4 _dispatch_client_callout 14 libdispatch.dylib 0x20a4d2324 _dispatch_lane_serial_drain$VARIANT$mp 15 libdispatch.dylib 0x20a4d2e40 _dispatch_lane_invoke$VARIANT$mp 16 libdispatch.dylib 0x20a4db4ac _dispatch_workloop_worker_thread 17 libsystem_pthread.dylib 0x20a70a114 _pthread_wqthread 18 libsystem_pthread.dylib 0x20a70ccd4 start_wqthread

surajthomask commented 5 years ago

@allenktv Is there any update on this issue? We are still facing these crashes and is really messing up the app stability metrics.

As an additional information, we do not pass nil to Firebase as value. In all places we are passing non-optional Any as the value and string as key.

We would really appreciate it, if this issue is resolved asap.

maximeavonvc commented 4 years ago

Hey everyone !

We have this same crash since 2 weeks, mainly on iPhone with iOS 13 and firebase 6.7.0. It appears when we added a lot of new tracking...

What is the situation about this crash ?

surajthomask commented 4 years ago

@maximeavonvc Apparently no one is looking into this :-( After my last comment on October 29th, we had this crash occurring 653 times affecting 566 users, that is single crash taking up more than 70% of all crashes, and there is literally nothing we can do about it, other than hoping that Firebase engineers picks this up.

alex-ost commented 4 years ago

+1, it's major crash for us.

TSkovsgaard commented 4 years ago

We have a lot of them, this is from a Swift project running on iOS 13

[__SwiftValue encodeWithCoder:]: unrecognized selector sent to instance 0x282a69f20

Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0x1998eea48 exceptionPreprocess 1 libobjc.A.dylib 0x199615fa4 objc_exception_throw 2 CoreFoundation 0x1997f25a8 -[NSOrderedSet initWithSet:copyItems:] 3 CoreFoundation 0x1998f2af4 __forwarding 4 CoreFoundation 0x1998f4a7c _CF_forwarding_prep_0 5 Foundation 0x199c9e144 _encodeObject 6 Foundation 0x199bb810c -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] 7 Foundation 0x199be313c -[NSDictionary(NSDictionary) encodeWithCoder:] 8 Foundation 0x199c9e144 _encodeObject 9 Foundation 0x199c03b88 +[NSKeyedArchiver archivedDataWithRootObject:] 10 APPNAME 0x104d90f20 -[TAGHitStore addPendingEvent:] 11 APPNAME 0x104d825d8 __29-[TAGContainer processEvent:]_block_invoke 12 libdispatch.dylib 0x1995ba610 _dispatch_call_block_and_release 13 libdispatch.dylib 0x1995bb184 _dispatch_client_callout 14 libdispatch.dylib 0x199567404 _dispatch_lane_serial_drain$VARIANT$mp 15 libdispatch.dylib 0x199567df8 _dispatch_lane_invoke$VARIANT$mp 16 libdispatch.dylib 0x199571314 _dispatch_workloop_worker_thread 17 libsystem_pthread.dylib 0x19960ab88 _pthread_wqthread 18 libsystem_pthread.dylib 0x19960d760 start_wqthread

Dertif commented 4 years ago

Same here, this is our top crash with 90% of our app crashes. @allenktv any plan on working to fix this any time soon ?

yellowgmk commented 4 years ago

We have the same problem here, it is also our main cause of crash in the application. It seems this problem has been going for a year now and has never been investigated because the issue keeps getting closed?

morganchen12 commented 4 years ago

The Tag Manager team has prepared a fix internally, but we do not know when it will be released.

Unfortunately, this has been the case for a while now.

surajthomask commented 4 years ago

@morganchen12 I'm relieved to know that this is being addressed by the team. Can you please push for a release of this fix on priority? We would appreciate it over the moon. This crash is leaving our stability metrics in the bin.

Hoping for the best news..!

Last 90 days ->

Screenshot 2020-02-12 at 11 25 11 AM
FDavidse20 commented 4 years ago

@morganchen12 This crash is also by far our number 1 crash. We would really appreciate it enormously if there is a fix for this! Any ideas if that might happen anytime soon?

morganchen12 commented 4 years ago

We've upped the priority of the internal ticket and continued to bug the Tag Manager team to release the fix, but we do not know when their next release will arrive.

If you're affected by this bug, please share the amount/percentage of crashing sessions attributed to this bug. If there's enough crashes across a significant number of apps (which it seems like there is), it will help us raise the priority further.

I understand that this last step should not be necessary and that it's frustrating watching Firebase crash your app. Sorry everyone for the inconvenience.

FDavidse20 commented 4 years ago

@morganchen12 Thank you for your reply. For our app we've had to actually pause the phased rollout for a new version, because we got a velocity alert from Crashlytics for this crash. The app is rolled out to only 1% of the users, but it causes roughly a 1000 crashes a day. Which is already about 70% of all current crashes for all of our app versions. So we can't resume rollout for our current version of our app, because then the crashes would simply explode.

Dertif commented 4 years ago
Capture d’écran 2020-02-14 à 13 25 52

@morganchen12 : This is in the last 90 days. It represents 60% of total crashes of the same period

maximeavonvc commented 4 years ago

Hi everyone ! On our app, This issue has 16437 crashes affecting 13149 users for the last 90 days. And this is our number 1 crash...

Happy if that this crash may be fixed in a short future.

Dadoufi commented 4 years ago

Hi, It's also the number one crash on our app...

Would really apreciate if there was a fix for this issue as soon as possible.

FDavidse20 commented 4 years ago

@morganchen12, are they any updates yet about when the fix is going to be released? This issue still causes a lot of crashes for our app. And drops the crash free user percentage by more then 5%. It's by far our number one crash.

morganchen12 commented 4 years ago

Hey all. At this point I have bugged the tag manager team to the best of my ability and further agitating them will not speed up their release. The release is still in progress, but I do not have an ETA.

Fortunately, there is a workaround: this issue can be avoided by checking every Analytics event log call your app is making and ensuring that there are no Swift-only types (structs, non-@objc classes, and pure enums without a string or numeric raw value). This is potentially a lot of Analytics calls to check.

I'll try to add some diagnostic code to the Analytics SDK so it will emit warning logs if you're logging events with pure Swift values.

morganchen12 commented 4 years ago

Google-internal change cr/297637641 adds an Analytics warning when you log an event with parameters containing a Swift value that's not representable as an ObjC Foundation type, and is slated for the next release. Hopefully this will make it easier to debug while we continue to wait for a Tag Manager release.

surajthomask commented 4 years ago

@morganchen12 Thank you for bugging the tag manager team, and we do really appreciate pointing in Swift-only types direction. We have identified one event passing an enumeration case to analytics layer, and is fixing it now. And the timeline from which crash started appearing matches with the time we added that event. Once again, thank you very much. Hopefully this crash will go away with our next app release.

yellowgmk commented 4 years ago

For our application, we have 41,4% crashes and all crashes are due to Firebase/GTM. Also, I can't find a place in our code where we would pass a pure Swift type to Firebase. All values that we pass are Strings. When the app crashes, it's often at app startup, and often after distributing a new version of the app (via AppCenter or via the App Store). Usually it crashes once at startup, and then doesn't crash on the next launch.

morganchen12 commented 4 years ago

@yellowgmk if it's not related to Swift types, can you share the stack trace?

yellowgmk commented 4 years ago

Only once I could have the crash while the debugger was attached:

Screenshot 2020-03-02 at 16 56 06
ahmedAlmasri commented 4 years ago

+1

morganchen12 commented 4 years ago

@yellowgmk do you have the exception message as well, printed after the crash? Without it, it's not possible to tell if this is the same crash or a different one.

paulb777 commented 4 years ago

GoogleTagManager 7.1.3 was released today with a fix for this issue. Let us know how it goes.

morganchen12 commented 4 years ago

Note that the Swift-only value check will still be included in the next Firebase release, which should be out soon as well.

Thanks everyone for your patience!

yellowgmk commented 4 years ago

We've embedded GoogleTagManager 7.1.3 in our application, but it doesn't seem to solve the problem. We have trouble reproducing the problem, but our users have it consistently and we have about 50% crashes in our user base, all caused by this issue.

morganchen12 commented 4 years ago

@yellowgmk can you update to the latest version of Analytics and then try to force the crash by logging a Swift-only type?

google-oss-bot commented 4 years ago

Hey @ffittschen. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

google-oss-bot commented 4 years ago

Hey @ffittschen. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

google-oss-bot commented 4 years ago

Since there haven't been any recent updates here, I am going to close this issue.

@ffittschen if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

surajthomask commented 4 years ago

I can confirm that we don't have this crash anymore. So the issue was, as mentioned by @morganchen12 that we were passing a swift only type, in our case an enumeration case to the Firebase. Once we replaced that swift only type with it's rawValue, the crash disappeared.

If you have a central place where all analytics calls are routed through it's easy to find where these crashes are coming from. Convert the analytics info dictionary to Data with JSONSerialization.data(withJSONObject:, options:). And look for any crashes. If either key or value is a swift only type, it will crash. So fix them up. Hope this helps someone.