Repository navigation
Persistent crash in FTL quick_actions Android tests #170141
Description
Activity
/cc @jason-simmons @jonahwilliams to investigate, as the people familiar with the PR.
- added
on Jun 6, 2025 - added a commit that references this issue
on Jun 6, 2025 Symbolized the stack trace using the
android_debug_arm64build of commit 8abf4e7A call to
ContextVK::CreateCommandBufferapparently returned null. This caused a crash when theContentContextconstructor tried to callCreateBlitPasson the null command buffer.flutter/impeller/renderer/command_buffer.cc:52 flutter/impeller/entity/contents/content_context.cc:576 flutter/third_party/libcxx/include/__memory/unique_ptr.h:754 flutter/impeller/display_list/aiks_context.cc:21 flutter/third_party/libcxx/include/__memory/allocator.h:153 flutter/third_party/libcxx/include/__memory/allocator_traits.h:309 flutter/third_party/libcxx/include/__memory/shared_ptr.h:734 flutter/third_party/libcxx/include/__memory/shared_ptr.h:742 flutter/shell/gpu/gpu_surface_vulkan_impeller.cc:57 flutter/third_party/libcxx/include/__memory/unique_ptr.h:754 flutter/shell/platform/android/android_surface_vk_impeller.cc:52 flutter/shell/platform/android/android_surface_dynamic_impeller.cc:37 flutter/shell/platform/android/platform_view_android.cc:416 flutter/shell/common/platform_view.cc:68 flutter/third_party/libcxx/include/__functional/function.h:995Hmm, is the command pool geting reset while its in use.
Do we get any validation errors with --enable-vulkan-validation?
Reproduced this locally on a Pixel 3 by running the
io.flutter.plugins.quickactionsexample.QuickActionsTesttest suite and reenabling theappShortcutLaunchActivityAfterStartingtest.A Vulkan validation error is logged midway through the tests (during the
quickActionPluginIsAddedtest)--- Vulkan Debug Report ---------------------------------------- | Severity: Error | Type: { Validation } | ID Name: VUID-vkDestroyCommandPool-commandPool-00041 | ID Number: -1387836198 | Queue Breadcrumbs: [NONE] | CMD Buffer Breadcrumbs: [NONE] | Related Objects: CommandBuffer [516903660592] [EntityPass Command Buffer], CommandPool [769658139443900] [UNNAMED] | Trigger: Validation Error: [ VUID-vkDestroyCommandPool-commandPool-00041 ] Object 0: handle = 0x7859dbec30, name = EntityPass Command Buffer, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x2bc00000002bc, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0xad474cda | vkDestroyCommandPool(): (VkCommandBuffer 0x7859dbec30[EntityPass Command Buffer]) is in use. The Vulkan spec states: All VkCommandBuffer objects allocated from commandPool must not be in the pending state (https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html#VUID-vkDestroyCommandPool-commandPool-00041)This crash happens because
ContextVKwas using a thread-local counter to assign the value returned byContextVK::GetHash.CommandPoolRecyclerVKuses these hashes as keys in a process-wide global map, and it depends on the key being unique for each activeContextVKinstance.This test was creating an Android activity containing a Flutter view, spawning another activity containing a Flutter view, and then returning to the first activity. The second activity's engine used different task runner threads. Because the
ContextVKassigned hashes using the thread-local counter, theContextVKcreated by the first engine had the same hash as the one created by the second engine.When the second engine shut down, it called
CommandPoolRecyclerVK::DestroyThreadLocalPoolsto destroy all pools associated with the second engine'sContextVKhash. But since the first engine had the same hash, its pools were also destroyed. The first engine was then unable to create command buffers when the first activity was restored to the foreground.- added a commit that references this issue
on Jun 25, 2025 - added a commit that references this issue
on Jun 25, 2025 - added a commit that references this issue
on Jun 25, 2025 - added a commit that references this issue
on Jun 26, 2025 - added a commit that references this issue
on Jul 7, 2025 This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Jul 9, 2025 - added a commit that references this issue
on Sep 28, 2026
The flutter/flutter -> flutter/packages roller is very behind due to persistent failures in
quick_actionstests, and by binary searching the roller failures I've narrowed it down to:8b18dde...8abf4e7
It's definitely not the README.md change, which leaves #169548 as the cause of the regression.
I don't have a lot of details about what's going wrong; it repros on FTL, but not our emulator tests (I guess those probably don't have Impeller support?) so may require a physical device to repro. Here's an example failure:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8712810564588405377/+/u/Run_package_tests/Firebase_Test_Lab/stdout
with the details being at
https://firebase.corp.google.com/project/flutter-infra-staging/testlab/histories/bh.7ef00c6ad97f5668/matrices/7655350001675281711
The crash is:
but I'm not sure if there's a way to symbolicate that.
The failing test is
appShortcutLaunchActivityAfterStarting, whose logic is hereI can disable the test for now to unblock the roller, but the fact that the change is reliably crashing a test app is concerning.