-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Crashed: com.google.iid-token-operations (QOS: UTILITY) #402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Can you give more details how you set up the NSOperation to execute the RemoteConfig code? Is it a background operation? Are you running it on main queue? It seems like that conflicts with what's inside InstanceID, which also uses NSOperation. But if you can provide more details that will help us to repo the case. Thank you! |
Thanks for your reactivity, Here is the full class:
I have a manager with configure the nsoperationqueue like this:
I had the operation this way:
|
This crash happened to me on podfile.lock:
Edit: |
I have the same issue, but I am using Firebase only from main queue. |
If you're having the same issue, please post stack traces as well--the nature of this crash means we won't necessarily be able to diagnose it from a single stack trace. If you're able to reproduce it locally, please try running your project with Xcode's built-in diagnostic tools enabled (NSZombies, asan, tsan), and post any traces here as well. Also note it's not safe to write to the FIRRemoteConfig shared instance from a background thread, as the FIRRemoteConfig class is not thread-safe. |
I cannot reproduce it locally, but here is a stack-trace of threads.
|
I also have this problem, would like to know when to repair? |
I can change the main of the operation like this :
|
@mgstudio the completion handler is always executed on the main queue, even if you call one of the fetch methods from a background queue. |
@morganchen12 does this solution to use GCD seems the correct solution for you ? |
@mgstudio Yes, that looks correct. |
Hi, Here is an example of full logs from crash, I hope this will help ;) :
--
|
Getting same error. Here's my stack trace in case that helps:
|
Thanks everyone. We have a fix in next release that is coming out soon. |
Same on my side :0. Wasn't doing anything special.
|
Thanks @chliangGoogle, as my app is crashing due to Firebase too, I was wondering when are you planning to make a release with this fix in it? I would like to plan a release of my app with updated Firebase SDK. |
The fix is planned for the next release, but we don't pre-announce dates. We'll update this issue when the fix is available. |
4.6.0 was just released (https://firebase.google.com/support/release-notes/ios). Looks like it contains the fix. |
Yep, this was fixed in the latest release. Feel free to reopen or file a new issue if this regresses. |
Great news, thanks! |
👍 |
I still have this issue with latest release :( Crashed: com.google.iid-token-operations :: NSOperation 0x1742f5300 (QOS: UTILITY)
0 libobjc.A.dylib 0x18e1981a0 objc_retain
1 Heetch 0x10054db70 +[FIRLoggerWrapper logWithLevel:withService:withCode:withMessage:withArgs:]
2 CoreFoundation 0x18f720e80 __invoking___
3 CoreFoundation 0x18f6162c4 -[NSInvocation invoke]
4 Heetch 0x10056eb48 +[FIRInstanceIDLogger logWithLevel:withService:withCode:withMessage:withArgs:]
5 Heetch 0x10056ecfc -[FIRInstanceIDLogger logFuncDebug:messageCode:msg:]
6 Heetch 0x10057148c -[FIRInstanceIDTokenFetchOperation performTokenOperation]
7 Foundation 0x1901ebbb0 __NSOQSchedule_f
8 libdispatch.dylib 0x18e5d29a0 _dispatch_client_callout
9 libdispatch.dylib 0x18e5e0ad4 _dispatch_queue_serial_drain
10 libdispatch.dylib 0x18e5d62cc _dispatch_queue_invoke
11 libdispatch.dylib 0x18e5e2a50 _dispatch_root_queue_drain
12 libdispatch.dylib 0x18e5e27d0 _dispatch_worker_thread3
13 libsystem_pthread.dylib 0x18e7db100 _pthread_wqthread
14 libsystem_pthread.dylib 0x18e7dacac start_wqthread Podfile.lock - Firebase/Core (4.6.0):
- FirebaseAnalytics (= 4.0.5)
- FirebaseCore (= 4.0.11)
- Firebase/RemoteConfig (4.6.0):
- Firebase/Core
- FirebaseRemoteConfig (= 2.1.0)
- FirebaseABTesting (1.0.0):
- FirebaseCore (~> 4.0)
- Protobuf (~> 3.1)
- FirebaseAnalytics (4.0.5):
- FirebaseCore (~> 4.0)
- FirebaseInstanceID (~> 2.0)
- GoogleToolboxForMac/NSData+zlib (~> 2.1)
- nanopb (~> 0.3)
- FirebaseCore (4.0.11):
- GoogleToolboxForMac/NSData+zlib (~> 2.1)
- FirebaseInstanceID (2.0.6)
- FirebaseRemoteConfig (2.1.0):
- FirebaseABTesting (~> 1.0)
- FirebaseAnalytics (~> 4.0)
- FirebaseInstanceID (~> 2.0)
- GoogleToolboxForMac/NSData+zlib (~> 2.1)
- Protobuf (~> 3.1) |
With the upcoming #444 PR and CocoaPods 1.4.0, we can eliminate the calls via reflection in InstanceID to FirebaseCore. It's not clear why the reflection based calls would cause this crash, but making the change could either eliminate the crash or provide more clarity about it. |
Also still happens for me: http://crashes.to/s/69c3aaca02d
|
This case is still occurred with 4.6.0!! Are you doing something about this in progress or not? In my opinion, exchanging the deprecated FIRInstanceID to the Messaging might be related with this case.. |
@paulb777 now that we deprecated FirebaseCommunity, should we revert the reflection code? |
@chliangGoogle Yes, reflection code is no longer needed for FirebaseInstanceID to make calls into FirebaseCore. |
v4.6.0 is still occurred for me too |
We are removing the reflection calls that causing the crash. Should be out for the next release. |
I still have this issue with latest release (4.7.0)
|
The fix hasn't been released yet. |
I'm having the same issue, here's the crash log:
|
Just so that you are aware of the severity: this bug is the Nr.1 reason for all the crashes in our App. It's high above any other source of crashes. |
Same here |
I'm seeing the same here. #1 crash in our app. When I see it in our app, there is always one or two threads waiting or executing sqlite ( ours or firebases ). Could be somehow related. |
Likewise, this has taken over the number one spot in Crashlytics for our app. |
This seems to be a "me too" day so if it helps, I can also confirm this crash happens frequently (unfortunately not frequently enough to be reproducible on my side) and has been the number one crash in my 4 apps. |
This should be fixed in the 4.8.0 release of Firebase, feel free to reopen if that's not the case. |
This crash is still occurred with 4.8.0!! :( Crashed: com.google.iid-token-operations :: NSOperation 0x1700e9200 (QOS: UTILITY) 0 libobjc.A.dylib 0x183d001a0 objc_retain + 16 1 my_app 0x100710ee8 +[FIRLoggerWrapper logWithLevel:withService:withCode:withMessage:withArgs:] + 1184628 2 CoreFoundation 0x185288e80 __invoking___ + 144 3 CoreFoundation 0x18517e2c4 -[NSInvocation invoke] + 292 4 my_app 0x1007599cc +[FIRInstanceIDLogger logWithLevel:withService:withCode:withMessage:withArgs:] + 1482328 5 my_app 0x100759b80 -[FIRInstanceIDLogger logFuncDebug:messageCode:msg:] + 1482764 6 my_app 0x10075c310 -[FIRInstanceIDTokenFetchOperation performTokenOperation] + 1492892 7 Foundation 0x185d53bb0 __NSOQSchedule_f + 228 8 libdispatch.dylib 0x18413a9a0 _dispatch_client_callout + 16 9 libdispatch.dylib 0x184148ad4 _dispatch_queue_serial_drain + 928 10 libdispatch.dylib 0x18413e2cc _dispatch_queue_invoke + 884 11 libdispatch.dylib 0x18414aa50 _dispatch_root_queue_drain + 540 12 libdispatch.dylib 0x18414a7d0 _dispatch_worker_thread3 + 124 13 libsystem_pthread.dylib 0x184343100 _pthread_wqthread + 1096 14 libsystem_pthread.dylib 0x184342cac start_wqthread + 4 Podfile.lock - Firebase (4.8.0): - Firebase/Core (= 4.8.0) - Firebase/Core (4.8.0): - FirebaseAnalytics (= 4.0.5) - FirebaseCore (= 4.0.13) - Firebase/Crash (4.8.0): - Firebase/Core - FirebaseCrash (= 2.0.2) - Firebase/DynamicLinks (4.8.0): - Firebase/Core - FirebaseDynamicLinks (= 2.3.1) - Firebase/Messaging (4.8.0): - Firebase/Core - FirebaseMessaging (= 2.0.8) - Firebase/RemoteConfig (4.8.0): - Firebase/Core - FirebaseRemoteConfig (= 2.1.0) - FirebaseABTesting (1.0.0): - FirebaseCore (~> 4.0) - Protobuf (~> 3.1) - FirebaseAnalytics (4.0.5): - FirebaseCore (~> 4.0) - FirebaseInstanceID (~> 2.0) - GoogleToolboxForMac/NSData+zlib (~> 2.1) - nanopb (~> 0.3) - FirebaseCore (4.0.13): - GoogleToolboxForMac/NSData+zlib (~> 2.1) - FirebaseCrash (2.0.2): - FirebaseAnalytics (~> 4.0) - FirebaseInstanceID (~> 2.0) - GoogleToolboxForMac/Logger (~> 2.1) - GoogleToolboxForMac/NSData+zlib (~> 2.1) - Protobuf (~> 3.1) - FirebaseDynamicLinks (2.3.1): - FirebaseAnalytics (~> 4.0) - FirebaseInstanceID (2.0.6) - FirebaseMessaging (2.0.8): - FirebaseAnalytics (~> 4.0) - FirebaseCore (~> 4.0) - FirebaseInstanceID (~> 2.0) - GoogleToolboxForMac/Logger (~> 2.1) - Protobuf (~> 3.1) - FirebaseRemoteConfig (2.1.0): - FirebaseABTesting (~> 1.0) - FirebaseAnalytics (~> 4.0) - FirebaseInstanceID (~> 2.0) - GoogleToolboxForMac/NSData+zlib (~> 2.1) - Protobuf (~> 3.1) |
Thanks for the fix, I do not experience this bug anymore in 4.8.0. But I got some other: http://crashes.to/s/a8fa82e0118 But this are happening very rare, nothing severe like the |
@Jeheonjeol The fix is actually in FirebaseInstanceID 2.0.8 which is the default for Firebase 4.8.0. It looks like you may be overriding the InstanceID pod version, since your Podfile.lock shows FirebaseInstanceID 2.0.6. @DarkoDamjanovic Thanks for the feedback. One of the other crashes you're seeing is being tracked in #431. I'm going to lock this issue for comments. If you see additional crashes, please open a new issue with the backtrace. |
Environment
POD file
Resuted pod file Lock
The problem
It append on few of my user since, I have this crash on crashlytics.
Crashlytics indicate :
The stack trace indicates that heap corruption may have caused your app to crash. Memory corruption can occur pretty easily from freeing a dangling pointer, a thread race, or bad pointer arithmetic. The important thing to keep in mind is that the resulting crash may happen long after the initial corruption. As a result, the stack trace for this crash might not provide any clues to the location of the bug in your code. However, you can still fix memory issues with tools from Apple. For speedy resolution of memory corruption issues, we recommend regularly auditing your app with Xcode’s memory debugging facilities: Visual Memory Debugger, Zombies Instrument, Address Sanitizer, Thread Sanitizer and malloc diagnostics.
LOGS
Relevant Code:
I'm using a subclasse of NSOperation to execute this code:
I'm also using FirebaseAnalytics but I can't found in the logs witch part of my code generate this crash. Which seems to be internal.
The text was updated successfully, but these errors were encountered: