Open Lariay opened 2 years ago
I also get bug reports with android 11 and my game. Are your errors with the same version of android (version 11)?
I getting 11 and 12 android versions.
Yes, I get tons of these errors, hundreds of thousands of people play mine, and my Google Play Console reports tens of thousands of crashes every day.
backtrace:
#00 pc 0000000000019e0c /system/lib/libc.so (memcpy+112)
#00 pc 00000000006988fc /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000000352a68 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000013a8590 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000013fa5d8 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000015f37cc /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 000000000160671c /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000001607f90 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000001609044 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000015f2c40 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 000000000160671c /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000001607f90 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000001609044 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000002b9ea0 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000002aff7c /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000000287258 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000000287298 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000000776be0 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000013fa550 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000007782b0 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 000000000077c4f8 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 0000000000769fa4 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000013fc708 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000013f46cc /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000013f49b0 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 000000000079ad20 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 00000000000c7e88 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000)
#00 pc 000000000008d480 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/split_config.armeabi_v7a.apk!lib/armeabi-v7a/libgodot_android.so (offset 0x89000) (Java_org_godotengine_godot_GodotLib_step6)
#00 pc 0000000000020137 /data/app/ru.skanersoft.bunker-KCTzfupiiX_vJS2PsNDBzA==/oat/arm/base.odex (offset 0x20000) (org.godotengine.godot.GodotLib.back [DEDUPED]+94)
#00 pc 0000000000024a8d /dev/ashmem/dalvik-jit-code-cache (deleted)
Yes, I get tons of these errors, hundreds of thousands of people play mine, and my Google Play Console reports tens of thousands of crashes every day.
And it's terrible. We cannot get a feature or a good organic traffic when we have 20+% of crashes.
Note that the latest "stable" version of 3.4 is 3.4.2, and we are already on betas for 3.4.3: https://godotengine.org/article/release-candidate-godot-3-4-3-rc-1
It is highly advised to use the latest point release to get all the latest bug fixes (unless there has been some regression which breaks an earlier version, which we try to avoid), this may be a bug that has been fixed.
Also afaik, GLES3 is not recommended on mobile. I've always used GLES2 for mobile and HTML5. See: https://godotengine.org/qa/125583/android-and-gles-3?show=125632
Note that the latest "stable" version of 3.4 is 3.4.2, and we are already on betas for 3.4.3: https://godotengine.org/article/release-candidate-godot-3-4-3-rc-1
It is highly advised to use the latest point release to get all the latest bug fixes (unless there has been some regression which breaks an earlier version, which we try to avoid), this may be a bug that has been fixed.
We have tried all minor and major releases from version 2.1.3 to 3.4.2 and nothing has changed over the years. The console is still full of inexplicable crashes. Compiling with separate debugging symbols would help, but Godot does not support this feature and is not even going to
And this should be fixed in 3.4. https://github.com/godotengine/godot/issues/38053
And this should be fixed in 3.4. #38053
There's many ways for a crash to happen, there's no indication at this time that the issue reported here would be the same as #38053.
Compiling with separate debugging symbols would help, but Godot does not support this feature and is not even going to
What do you mean with "is not even going to"?
Currently you can compile a debug template with debug symbols using target=debug
. If you want to implement a way to compile with debug symbols in a separate file that can be uploaded to the Google Console, that's definitely something we could review.
There's many ways for a crash to happen, there's no indication at this time that the issue reported here would be the same as #38053.
And what we must to do? We don't know what is it, how to fix it. Crashes like that happened from 2.1 Godot to 3.4.2 and they have huge impact on developers and studios who select Godot Engine as main engine.
I decided not to do anything, I once wrote about this (long ago) but nothing has been fixed. I've been getting these errors consistently for over a year, including the latest up to date version 3.5 beta 1, these errors don't change.
Just to provide some info on Android debugging - to debug Android in general the minimum needed to start with might be something like:
Along with the usual stuff like
A crash without debug symbols is rarely enough information to go on on its own. You will usually need access to the hardware that fails and have it cabled to a PC.
In general I personally would advise against using GLES3 on Android, as there are too many things that can go wrong, I'm not sure whether we are officially supporting GLES3 on Android at this stage (I'm just a contributor not a spokesperson :slightly_smiling_face: ).
As it says in the new project dialog, GLES3 may not work on older hardware, and this is especially the case with Android, I would personally expect it to crash / malfunction on a large percentage of users. So I would make a copy of any project and convert to GLES2 and start from there.
I would also usually advise against using custom shaders on Android unless you really know you are doing because you are highly likely to run into hardware issues / hardware bugs, you would have to investigate and work around these yourself. This normally involves studying the relevant GLES API spec, mandated features, checking out the caps of target hardware and working to constraints.
As an open source project we don't have massive (any! :grin: ) resources to investigate particular problems on specific hardware so we have to rely on users to do a lot of the work, and interest from a capable developer who is likely donating their spare time for free. Also bear in mind Android is problematic for compatibility not just for Godot, but for all devs. I've had to deal with similar issues prior to working with Godot, it comes with the territory unfortunately.
I think it makes sense to implement at least Native Crash support in the build system
Getting just about the same stack trace with my releases on GooglePlay, also can confirm that most of the devices it crashes on are Samsungs are Xiaomis. Faced this on both 3.4.3 and 3.4.4. I am not sure how to push a release version to Google Play with debug symbols included. If anyone could help me on this, I would do that and publish the stack trace with debug symbols in this thread. Currently it's kinda frustrating to get such crashes on a 2nd game powered by Godot. I can't reproduce these crashes on any of my devices, but I was lucky enough to chat with a person who experienced a crash and it seems it has something to do with load("res://...") method judging by what the person did to get the crash (and it basically was pressing a button that doesn't do anything special and just loads a scene).
Renderer doesn't have anything to do with it, apparently. My 1st release was GLES3 and 2nd release was GLES2, still getting crash reps.
any news on that topic ?
I'm seeing the same report from my Google Play Console. The only crash that was consistently happening was on a Pixel 2 arm64 emulator. Simply wouldn't launch:
https://github.com/godotengine/godot/assets/137741188/53702c1f-40fb-4c80-afe3-bccc838a6156
Though I will note, this is Godot 4, so this may not be the same problem anymore, unsure if I should create a new issue for this. Also, here's the reported console output: https://pastebin.com/wfAWYw0i
EDIT: I was able to resolve this: https://github.com/godotengine/godot/issues/58139#issuecomment-2142722528
Note that the latest "stable" version of 3.4 is 3.4.2, and we are already on betas for 3.4.3: https://godotengine.org/article/release-candidate-godot-3-4-3-rc-1
It is highly advised to use the latest point release to get all the latest bug fixes (unless there has been some regression which breaks an earlier version, which we try to avoid), this may be a bug that has been fixed.
Also afaik, GLES3 is not recommended on mobile. I've always used GLES2 for mobile and HTML5. See: https://godotengine.org/qa/125583/android-and-gles-3?show=125632
I really don't think blindly saying "just upgrade to the latest version" is useful advice. It can lead people astray and make it seem like a problem is solved when it really isn't. It can also introduce new issues for them, which can distract from the problem at hand.
In this case, the problem is still not solved, years later.
I really don't think blindly saying "just upgrade to the latest version" is useful advice.
Sorry I should have been more explicit in what I meant here by "latest point release" as readers may not be familiar with semantic versioning:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backward compatible manner
- PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
When we release a MINOR version (e.g. 3.4) we read bug reports and attempt to fix bugs. As we fix them, we release new versions in a PATCH release (e.g. 3.4.1, 3.4.2 etc, we are now at 3.4.5).
We don't re-release 3.4 itself with bug fixes, because that would be incredibly confusing because we wouldn't know which 3.4 it was. We try as much as possible not to introduce new bugs in PATCH releases, but there can be no absolute guarantees, because software includes many components that interact with each other in sometimes unexpected ways.
We always advise to use the latest PATCH release simply because we know that earlier PATCH releases contain bugs, and there is no point (for anybody) in spending time trying to identify and fix bugs that are already fixed.
MINOR versions are different as you say, as they can introduce new features, new ways of working, and new bugs.
See https://docs.godotengine.org/en/latest/about/release_policy.html#release-support-timeline for more info.
If you don't know of a patch or version that addresses the issue at hand yet you still advise updating, then you are blindly telling a user to update.
In this case, the user can update and the problem will still exist.
If you don't know the solution to a problem, it's okay to refrain from giving automated responses that will distract and delay.
I had forgotten that I had posted on this issue - I was able to resolve this on my end by switching the rendering backend from Forward+ to Compatibility. However, I'm using Godot 4.2 in this instance, so it may not be relevant.
Just as it doesn't seem mentioned in this thread, I would like to remind all that setting correct Android permissions in the export settings is vital, and this has often been the cause of Android crashes (app tries to do something like write a file it doesn't have permission for, it fails and the app crashes).
The engine currently doesn't deal with permissions very well afaik. If we could query the permissions at runtime (either through the OS, or storing a database in the APK) before attempting operations that might crash, that would be useful.
Godot version
3.4 stable
System information
Android devices, Build system - Linux, Gles3
Issue description
In android developer console I getting a huge crashes:
Repeated on different android devices. On my personal + 10 testers could not find and repeat such a failure. Therefore, I cannot fix this problem in any way. 20% of users are affected by this problem and I don't know how to solve it. I found information on this error in Google, but it says that it will be fixed in the 3.4 version of the engine.
Occurs on completely different processors. Most often cases on: Redmi Note 8 Pro Samsung Galaxy A50
But I think that there is no connection here, it’s just that people have the most of these devices.
Steps to reproduce
No steps.
Minimal reproduction project
Game can be installed from google play: https://play.google.com/store/apps/details?id=games.misu.zombie.room.survival.game