Android editor crash when interacting with some GUI elements #94741
Comments
|
I'm tentatively putting this in the 4.3 milestone / blockers that we track as it's a regression from a 4.3 PR. But I don't consider it high priority at this stage so close to the release, as it's a crash in the Adreno GPU driver and thus probably a driver bug. Figuring out a workaround might take a while as it might be difficult to reproduce. Still, CC @DarioSamo who wrote the ARG PR, and @Alex2782 @m4gr3d @clayjohn who are used to debugging Android driver bugs. |
|
We have a list of devices that were affected by a similar regression. Perhaps this device just needs to be added to the detection here. I say try forcing this particular workaround to true and see if it fixes the issue for you first. godot/drivers/vulkan/rendering_context_driver_vulkan.cpp Lines 530 to 553 in e343dbb |
This comment was marked as outdated.
This comment was marked as outdated.
|
@matheusmdx To me it looks like an emulator, or is it something like a 'RemoteViewer' ? from Logs:
|
I changed for a hardcoded true but the crash persists
I cherry-picked this pr but unfortunately not worked too
This is a remote view, scrcpy: https://github.com/Genymobile/scrcpy. I used that to make the testing more faster, but i also tested without using this to make sure that didn't had any interference in the tests. I can help test any possible solution, just gimme the instrusctions/apk. I also can try get a better backtrace if exists any way to get a more complete one, |
|
You can get a backtrace with debug symbols by passing Btw @m4gr3d we really need to document this on https://docs.godotengine.org/en/latest/contributing/development/compiling/compiling_for_android.html We should probably still document the various Gradle task for advanced users. |
Seems we're pretty much in the situation of having to debug and find yet another workaround for a particular Adreno device because the Render Graph changed the order of operations then. Unfortunately the regression will point you to that particular commit, but it's just a situation of being lucky enough to not run into the driver bug before and now we are. You can try messing around with these two macros and see if you get any different results, as these will make the render graph basically regress into the behavior of the previous version: godot/servers/rendering/rendering_device.cpp Lines 104 to 117 in e343dbb |
This comment was marked as outdated.
This comment was marked as outdated.
I tried this but
Changing
Here what was printed, i just opened the editor and when editor loaded i triggered the crash: print render graph.txt |
|
Thanks for testing!
I will revise PR #92611. //TODO: check 'driverVersion'?
// no crash on Fujitsu F-01L - Adreno (TM) 506, Vulkan 1.0.61, driverVersion = 54185879
r_device.workarounds.force_material_uniform_set =
r_device.vendor == VENDOR_QUALCOMM &&
p_device_properties.deviceID >= 0x5000000 && // Adreno 5xx
p_device_properties.deviceID <= 0x5999999;I'm not sure exactly which driver versions they are. p_device_properties.deviceID >= 0x6000000 && // Adreno 6xx
p_device_properties.driverVersion < VK_MAKE_VERSION(512, 503, 0) |
Pretty much fits the exact same situation of the other Adreno crash that the workaround was introduced for, where basically Godot was lucky enough to not crash on this particular hardware, but reordering the operations triggers the error in the driver. The problem is not reordering the graph in this particular hardware would just be hiding the issue, because as soon as the renderer changes its behavior, it could reintroduce the error again. We're much better off investigating what exact sequence of events makes the driver crash here so the render graph can insert workarounds as needed, which would guarantee the renderer never breaks on this hardware in the future. Without this particular hardware however, we're left pretty much guessing at this point. I'm afraid you'll have to dig deeper into it, probably by simplifying the project as much as possible and looking at the output of the render graph, and potentially modifying what looks like could be the problem. When dealing with a driver bug, we don't really have much left to review on our side as it's basically dealing with a black box where some behavior that is known to be correct just doesn't work. One possible hint I'll give is that the previous crash was related to the relation between compute and drawing, and the old version was guaranteed to dispatch compute first before doing any drawing on the frame. Reordering can cause drawing to happen before compute, and that's what triggered the crash. You said you verified the workaround didn't fix it for you, but so far it's sounding like the exact same issue. I think it's probably worth double checking. |
Maybe same issues. There are MRP to reproduce it outside the editor. @matheusmdx: If you have time, please try it out.
Some stats / PlayStore Device Catalog
The older the Android devices are the more unusable they become, older Android versions also have older drivers and Vulkan API (1.0.x on Android 8 and 7). I think only from Android 9 devices Vulkan API 1.1.x is it worthwhile to invest more effort to fix exotic bugs. Up to 650 devices with Adreno 5xx GPU (approx. 3.75%). In Playstore, the installation figures would still have to be taken into account. For example, over 70% of our PlayStore customers already use Android 13+ devices, which is a "normal" app for ordering a cab. Android 9 is even at only 2%! 275 / 17339 * 100 = 1.59% * 2% * 100 = 0.0318% (?) of our customers could still have an Adreno 5xx with Android 9. |
|
@zhmt: Xiaomi Redmi Note 11 Pro 5G, Snapdragon 695, We have driver ( According to your logs, it looks like a normal Godot issue |
|
@Alex2782 |
|
@DarioSamo @Alex2782 I'll test the other mrp's and try find something. What i should look in the print render graph results? Like what result should be normal and what is a bug.
Yep, that stops the crash |
|
Also @akien-mga any idea why the debug symbols doesn't work? Get a full backtrace would help a lot. |
My recommendation is to render fewer frames: func _ready():
Engine.max_fps = 5
print("======== READY ========")
Analyze what happens before the crash, but also what happens between several
|
Since you're building the editor, I think there's no pre-defined task for not-stripping it. You could add the godot/platform/android/java/build.gradle Line 284 in 607b230 Or copy it and make a generateDevEditor task for that.
CC @m4gr3d |
|
@matheusmdx you can generate a dev build of the editor with no-stripping using the following command build: For reference:
For debugging the Android editor, I'd recommend using Android Studio. There's support for setting breakpoints both in java and c++ allowing you to walk through the code line by line to identify the source of the crash. |
Good idea, I'll update the documentation with instructions for advanced users. Note that we'll need to merge #92859 to address a regression with how stripping is set in the latest versions of gradle. |
|
@m4gr3d I was able to build the apk with your instructions, now i just need some help how i do to debug using android studio, i tried use "attach debbuger to android process" but that didn't worked. Also here the backtrace with a dev build: |
|
Already configured as in the description? I also had some crashes where the debugger did not work properly, no breakpoints were positioned. Android Studio / Editor - Dev Build consumes an incredible amount of memory. At least 16 GB necessary, better 32 GB. Because the error occurs in the driver, debugging is less useful: |
I tried the mrps from this issues but all of them crash for me on editor while loading, here the prints they generate before the crash 79760 CircleJumpGodot4.txt New project + click on renderer switch.txt I'll do more test this week changing some code to see what happens, also if anyone want to test something else feel free to tell me. I was able to use the android studio so i can get better backtraces and check parameters if necessary:
|
|
@matheusmdx thanks! please try #92611 again. PR should be prepared, OutdatedSome information should appear in the logs as to whether the workaround has been activated and which driver version.Example on MacOS, which
I have not yet been able to confirm this with a 2D benchmark, The crash happens in the graphics driver, which is like a black box if no sources have been released for it.
I have tested on Firebase Test Lab, the 'uniform' shader is not fixed, with |
|
@Alex2782 Sorry for the late reply, i was a bit busy last week. This pr doesn't stop the crash, i took a look with android studio and seems that
|
|
Thank you! I'll try to revise it in the next few days. @matheusmdx: |
|
Now i didn't received a notification from your comment edit, but anyways @Alex2782 i can confirm now fixes the crash |
Tested versions
Reproducible: Latest master v4.3.rc.custom_build.e343dbbcc, 4.3 betas 1, 2 and 3.
System information
Godot v4.3.rc (e343dbb) - Android - Vulkan (Mobile) - integrated Adreno (TM) 506 - (8 Threads)
Issue description
Android editor crashes with a signal 11 after simple intereactions, only happens in vulkan mobile render, compatibility render works normally:
Example 1
unknown_2024.07.25-10.49.mp4
Example 2
unknown_2024.07.25-10.51.mp4
Example 3
unknown_2024.07.25-10.53.mp4
Backtrace
I bisected the issue to #84976:
Another detail is the editor don't crash if you create a Node2D or a Control node:
unknown_2024.07.25-11.13_1.mp4
Investigating futher i found that if you do any action that create the
editor_layout.cfgfile (creating a node and saving the scene or creating a node and reloading current project fromProject > Reload current project) makes the project don't crash anymore, but if i deleteeditor_layout.cfgagain or create the node but don't do any of the two actions i said above and kill the editor, the crashes come back.Steps to reproduce
See the videos above
Minimal reproduction project (MRP)
No needed, any new project can reproduce
The text was updated successfully, but these errors were encountered: