Android Emulator 36.6.11 on macOS arm64: intermittent RenderThreadInfoGl TLS assertion during fresh AVD boot

[DoDoENT]

Android Emulator intermittently aborts during a fresh headless AVD boot with:

FATAL | Attempted to set thread local GL render thread info twice.

The macOS crash report resolves the failure to RenderThreadInfoGl::RenderThreadInfoGl() in the bundled libgfxstream_backend.dylib. I could not find an existing report for this assertion. Please redirect this report if it belongs in the Android Emulator tracker instead.

Environment

• Android Emulator 36.6.11.0, build 15507667, official darwin-aarch64 binary.
• Confirmed crashing host: Apple M1 Mac mini (Macmini9,1), macOS 26.7 (25G229).
• Also running workloads across Apple M1 and M2 Pro hosts; the exact crash report below is from the M1.
• System image: system-images;android-24;default;arm64-v8a, revision 9.
• AVD: 2 guest CPU cores, 2048 MiB RAM, 2048 MiB data partition, 1080x1920, density 420, a separate writable AVD directory and 64 MiB SD card for each invocation.
• GPU mode: swiftshader, gfxstream backend. The log reports vulkan_mode_selected: swiftshader gles_mode_selected: swangle.
• Renderer: ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (LLVM 10.0.0) (0x0000C0DE)), SwiftShader driver-5.0.0).
• GLES: OpenGL ES 3.0 (OpenGL ES 3.1.0 (ANGLE 2.1.1 git hash: fbf66f49c7cc)).

Observed reproduction conditions

The crash was observed during repeated fresh AVD launches on native APFS while iOS Simulator was also running on the same host. It occurred on an M1 host with only one Android emulator running. Concurrent Android emulator instances on M2 Pro hosts have also been part of the observed workload. The failure is intermittent, not a deterministic reproduction, and happens during startup before any test APK is installed.

Representative emulator invocation (paths and allocated ports replaced with variables):

ANDROID_AVD_HOME="$unique_avd_home" \
ANDROID_SDK_HOME="$unique_sdk_home" \
emulator -avd hermetic-emulator-test \
  -port "$unique_even_console_port" \
  -no-window -no-audio -no-boot-anim -no-metrics \
  -no-snapshot -no-snapshot-save -wipe-data \
  -modem-simulator-port "$unique_modem_port" \
  -gpu swiftshader

Each invocation has a distinct AVD directory, console port pair and modem port. No snapshots are loaded. The same fatal message was also observed with swiftshader_indirect before switching to swiftshader.

Crash stack

Exception: EXC_CRASH (SIGABRT). The process had 39 threads. Faulting thread, newest frame first:

__pthread_kill + 8
pthread_kill + 296
abort + 148
absl::lts_20240116::log_internal::LogMessage::FailWithoutStackTrace() + 20
absl::lts_20240116::log_internal::LogMessage::SendToLog() + 148
absl::lts_20240116::log_internal::LogMessage::Flush() + 300
absl::lts_20240116::log_internal::LogMessage::~LogMessage() + 20
write_log_line(...) + 92
gfxstreamLoggingCallback(...) + 180
gfxstream::host::impl::GfxstreamLog(...) + 232
gfxstream::host::gl::RenderThreadInfoGl::RenderThreadInfoGl() + 176
gfxstream::host::RenderThreadInfo::initGl() + 52
gfxstream::host::RenderThread::main() + 152
gfxstream::base::Thread::thread_main(void*) + 84
_pthread_start + 136
thread_start + 8

Bundled libgfxstream_backend.dylib: arm64, UUID 4c4c4477-5555-3144-a1ef-503ca5cb863d.

Scope and uncertainty

The source assertion checks a non-null thread-local tlThreadInfo in the GL render-thread-info constructor. The crash stack reaches that constructor directly from RenderThread::main(). I have not established why it is already non-null, or proved that concurrent simulators are necessary to trigger it. There is no Hypervisor.framework frame in the faulting stack.

This report covers the captured 36.6.11 crash. Newer emulator versions have not yet been tested. Is there a known fix for this TLS assertion, or additional diagnostics we can enable to help identify the existing thread-local owner?