Android [split_config.arm64_v8a.apk!libc++_shared.so] std::__ndk1::recursive_mutex::lock() ANR #75893
Comments
|
Do these occur on latest 3.x? (i.e. 3.5.2?) Or is your project incompatible? Just in case some of these bugs are fixed. |
|
Judging by the stacktrace, this might also have been fixed by #65398, which is included in 3.6. We'll soon release 3.6 beta 1 which can be used for testing. |
|
OK. Tested on 3.5 only now. I will wait for the 3.6 beta 1 and then make an update to get more info. |
|
Same ANR in production with 3.6 beta 1. Following is a mix of 3.5.1 and 3.6 beta 1. Some devices it happens on: Some Android versions: Mostly happens when app is in the foreground. ALSO: This ANR is happening in game built with 3.3.0 mono. |
|
@ksvslk Do you use accumulated input or input buffering in your game? cc @RandomShaper, if the issue occurs despite either options being enabled, we may need to revisit the previous approach which would dispatch input events on a separate thread. |
I use the default values for these. |
|
@ksvslk Hi, Thank you! |
I'm using 3.5.3 stable now and have not seen these anymore. |
If you can, do let us know what version you experienced them in, so we can establish whether the fix worked, or the issue should be reopened. |
|
We are also using 3.5.3, but still getting the This ANR is predominant in low end devices. Our ANR distribution varies across RAM capacity as below: Google Play Console's threshold rate is 0.47%, and we are just above it at 0.48% Please let me know if you need any other info. Thank you. |
|
@lawnjelly Would you recommend cherrypicking #76839 on 3.5.3? |
I went from 3.6.beta2 to 3.5.3.stable. |
This seems to be a misconception, my PR there was primarily to improve agile input, it had the side effect of also potentially fixing the input thread calling user code and hence giving ANRs. This was written before another fix was merged to address the ANRs, so I can't guarantee that my draft PR would have any improvement. What we really need is a minimum reproduction project to examine ANRs. There are a lot of possible causes, and to suggest a PR might fix it is straying towards magical thinking. Things that are likely to cause a problem are things like advertising addons running on the input thread, or doing some other time sapping process. You can probably test this yourself by storing the input yourself and deferring your action, and acting on it instead inside
This suggests something is being done (on the input thread? but maybe also on the main thread, it's a while since I looked at this) which is taking too long to process and return control to the OS. Without an MRP, we have no idea what this might be, it might be user side, or something in the engine. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Godot version
3.6.1.beta
System information
Android, GLES2
Issue description
Multiple ANRs.
In Google Play Dashboard there is extra message about the ANR:
This native synchronization routine is blocking the main thread, causing an ANR
I'm using quite a few Android plugins (I put the all in one plugin):
I use also GodotGooglePlayBilling
I'm not sure if it is bug or misuse of the engine - but I cannot provide you the steps to reproduce or MRP.
Steps to reproduce
I cannot provide this.
Minimal reproduction project
I cannot provide this.
The text was updated successfully, but these errors were encountered: