libc.so Crash after updating to firebase unity sdk 8.6.1/8.6.2 #1193
Comments
|
I found a few problems with this issue:
|
|
Hi @AjayC-Bsw, In order to identify what's causing this, could you provide a minimal, reproducible example of your project along with the complete steps to replicate the issue? Could you also provide a complete stack trace along with the Firebase product/s used? |
|
We are having the same issue. We cant reproduce the bug ourselves, and the crashlytics doesn't give us much info also. The only thing we noticed is that the free memory of the crashed users is below 100MB for some 20MB. Happens on booth 8.6.1/8.6.2. |
|
@paulinon Firebase products used - Database, RemoteConfig, Fcm, installation, Crashlytics, Functions, Analytics Steps to Reproduce -
or Same thing Happens with When Rewards Ads comes in Landscape mode. We are using other crash reporting tools too that is not reporting any crash neither we are getting anything in logcat but Crashlytics shows app crashed. |
|
HI @AjayC-Bsw, It would be great if you provide a minimal, reproducible example of your project along with the complete steps to replicate your issue. I'm unable to begin my investigation with the provided infromation so far. |
|
@paulinon |
|
Hey @AjayC-Bsw. 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! |
|
We saw the same crash issue in our game after updating to 8.6.1/8.6.2 and needed to revert to the version we had previously integrated (8.1.0) in order to resolve. Similar to others, we were not able to repro the crash on test devices but it was occurring for 1% of players when live which would put us above the bad behavior threshold. Unity version 2019.4.30 |
|
Any news ? It was occurring for about 26% of all crashs in my app . All I know is this issue happens when low RAM free ( < 200mb , sometime 200-500mb ) . No problem with ver 8.1.0 , 8.2.0 |
|
yes. I find it write log and crash |
@yingnierxiao Please share your findings. |
|
Guys,
|
|
Hi @AjayC-Bsw and other folks in the thread, Version 8.7.0 of the SDK has been released recently. Could you try this out and see if it resolves the issue? |
|
Same Here! |
|
Guys, you really need to fix it... |
|
I have had this crash for a while now and followed this thread. Not sure if it helps but this is what I have figured out so far. By using logs in the game I have been able to track down where it is happening. And for all users that experiences this crash, the last line that is executed in my game is this: docRef.SetAsync(UserState).ContinueWithOnMainThread(task =>{...} Just before this line I have a log that is always triggered, and inside the response is another log that never gets called if they experience the crash. The "docRef.SetAsync" is called when users do certain things in the game (complete levels, buy coins, during startup etc). The crash happens sporadically, sometimes during syncing user state on startup, sometimes when they have played 100 levels, meaning 99 calls works just fine but then all of a sudden it does not.
Dependencies in the game:
Attached crashlogs I see on Google play. |
|
Google seem don't care about developers at all.
This crash remain from old version to this day.
…On Fri, Sep 9, 2022, 23:36 Ann Michélsen ***@***.***> wrote:
I have had this crash for a while now and followed this thread. Not sure
if it helps but this is what I have figured out so far.
By using logs in the game I have been able to track down where it is
happening. And for all users that experiences this crash, the last line
that is executed in my game is this:
docRef.SetAsync(UserState).ContinueWithOnMainThread(task =>{...}
Just before this line I have a log that is always triggered, and inside
the response is another log that never gets called if they experience the
crash.
The "docRef.SetAsync" is called when users do certain things in the game
(complete levels, buy coins, during startup etc). The crash happens
sporadically, sometimes during syncing user state on startup, sometimes
when they have played 100 levels, meaning 99 calls works just fine but then
all of a sudden it does not.
- I might be wrong, but I think this crash starts to happen once the
user state becomes bigger, I very rarely see it on new users.
- I also pushed a build to production with firebase.verbose logging
turned on. This did not result in any new information.
- I can not reproduce this on test devices.
- It does not happen in the background, the amount of support emails
on this tells me otherwise.
Dependencies in the game:
- Facebook, Firebase (analytics, messaging, crashlytics, remote
configs, Firestore), AppLovin Max
- using EDM, version 1.2.172
- No custom gradle
- Unity 2021.3.9f1 (but have tried 2020.x as well and same issue)
Attached crashlogs I see on Google play.
google_play_crash_log_1.txt
<https://github.com/firebase/quickstart-unity/files/9537201/google_play_crash_log_1.txt>
google_play_crash_log_2.txt
<https://github.com/firebase/quickstart-unity/files/9537205/google_play_crash_log_2.txt>
—
Reply to this email directly, view it on GitHub
<#1193 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADX7J7NQSK6N3KDNRWN4QOTV5NRPXANCNFSM5I4F3YCA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
we are using version 9.5.0, the problem continues. Until this is fixed we will go back to the previous version we were using 7.2.0 since we don't get these crashes on that version. |
|
Hi all, We are still looking into any underlying problems there might be, but after doing some investigation there is some clarification needed. The 8.6.1 version of Crashlytics added support on Android for collecting NDK crash reports in native libraries, with more information located here: https://firebase.google.com/docs/crashlytics/get-started?platform=unity#set-up-symbol-uploading The reason that these crashes started getting reported with this version is likely not a bug caused by this version, but instead these crashes were already happening, but were going unreported prior to that release. We are working on improving these crash reports, so that there is more clarity on what the problem is beyond the vague reports that are more likely to occur. |
|
Some users of my app who experience crashes have reported to me that the app is using an insane amount of memory on their devices (>800MB, while in my own tests the usage rarely exceeds 200MB on my own - crash free - Android devices). Could the core of the problem be a memory leak -- which for some reason only exists on specific devices? |
For your information 9.6.0, the problem continues. "We are working on improving these crash reports" Are you sure? |
It might be interesting to see attached image |
|
For the users that are seeing issues with Firestore, and running out of memory, what type of data are you trying to set? Like, how large is the data set, what type of information, etc. Based on the crash logs from @AnnMic it is running out of jni global memory, and it seems like it has a high number of java longs and hashmaps. We've been able to produce a similar crash on our end by pushing a map with 60,000 entries, and are investigating ways for it to use less global memory while doing so. |
|
@a-maurice Sorry thought I would get a notification once something happened in the thread... I can also reproduce this issue now and have a user state which always creates an android crash. Yes the issue seems to be having a large dictionary with data. But my dictionary only has 170 elements but can go six levels deep in worst case so it can include quite a lot of elements. Also it can potentially include a lot of strings. Since it's a word game, and currently it stores found words as strings on unfinished puzzles. I made a workaround (something that should probably have been there from the beginning but anyway). Removing the dictionary and instead it becomes a "Collection" at top user level on Firestore, the states inside the dictionary each becomes its own "Document" instead. It then no longer updates the full dictionary, but rather smaller documents. |
|
Hello! Nobody answered this:
More Info: we use Crashlytics, Analytics and RemoteConfig Only (9.4.0) Thanks |
|
It will not fix anytime soon. I don't have faith with them. Ah let mention another thing, on Unity's latest LTS version, on an EMPTY android project, building apk fails if you just import Firebase and Admob's latest version and try to building it on an empty scene. You need to fix it by yourself! Great guys! Seems like development teams behind Firebase Unity and Admob Unity don't care each other, and they don't even bother testing them together. |
Emmm... I think you may need create another issue for this. |
|
Yes, if you have other issues, please file new bugs for them to be tracked. For these crashes, any logs or callstacks that indicate where the problem continue to be useful. We've identified one problem in Firestore that we will have a solutions to soon, but that was an issue specific to Firestore, and thus won't help for the problems folks are seeing when not including it (like the ones seeing it with just Crashlytics, Analytics, and Remote Config). |
|
Hi all, so an update from my company, we updated Unity to 2021.3.9f1 and we still run Firebase SDK 9.0.0 and now that our latest build has had time to propagate our crash rate has finally dropped back under the bad behaviour threshold. Clearly our (My Company's) issue was Unity related, this may not be the case for others, but felt we should update this thread. |
|
For those of you that were having problems with Firestore, the latest release (https://github.com/firebase/firebase-unity-sdk/releases/tag/v10.1.0) has a fix to reduce the amount of global JNI references it uses, which will hopefully alleviate the problems that some of you all were having. We are still trying to look into more improvements to do there, as it is still possible to hit the limit of references with extremely large sets of data. We are aware that some of you are having problems not related to Firestore, and if you have any logs or callstacks that can help narrow down those problems, that would be appreciated. |
|
FYI the Firebase Unity SDK v10.1.0 was released on November 7, 2022 and includes firebase/firebase-cpp-sdk#1111, which reduces the number of global references consumed by Firestore by about 50%. This will hopefully address many cases of the "global reference table overflow" crash, such as the one reported by @AnnMic in the previous comment #1193 (comment). A full and proper fix is in development, but it is complex and is taking time to implement. Note that this won't necessarily fix all of the "libc.so crash" issues, but is at least one of them. |
|
This issue is a bit complicated to follow, due to multiple different issues being discussed. I have opened some other issues to track down the problems that have been identified in here. If you have information about those crashes, please use those issues, or if you have a different issue, open a new issue so that it can be discussed from a fresh point of view. |
|
Hi @a-maurice! I would like to keep following the discussions about this issue / issues (it's not solved for us yet), but I don't see any recently opened ones by you. Can you put links to those issues here? Thanks. |
|
@nronaldvdberg Ah, sorry. Firestore related crash: firebase/firebase-unity-sdk#569 Those were the two that I could identify based on the reports, but it is possible that there are different ones. The libc crash is a very generic "there was a problem on the C++ side" error, which is why I'd like to split them out into different issues if at all possible. |
[REQUIRED] Please fill in the following fields:
We are getting this crash after after to firebase Unity sdk 8.6.1.
Steps to reproduce:
Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)? Unable to repro
What's the issue repro rate? 1 % user impacted
LOGS:
The text was updated successfully, but these errors were encountered: