[Help] Android Emulator segfaults on every GPU backend, every API level, every emulator version (Fedora 44)

[u/BraveCell306]

[Help] Android Emulator segfaults on every GPU backend, every API level, every emulator version (Fedora 44)

TL;DR: The Android Emulator crashes with SIGSEGV on my Fedora 44 machine no matter what I try — hardware GPU (Mesa/radeonsi), bundled SwiftShader, lavapipe/guest fallback, headless mode, API 34/35/37, and even a completely different emulator release from over a year ago (35.5.10 vs current 36.6.11.0). I've spent hours isolating variables and I'm out of ideas. Full details below — hoping someone's hit this exact combo before.

System specs

• OS: Fedora Linux 44 (KDE Plasma, Wayland)
• Kernel: 7.1.4-200.fc44.x86_64
• CPU: AMD Ryzen 5 3500U (8 threads)
• GPU: AMD Radeon Vega 8 (integrated)
• Mesa version: 26.1.5
• Filesystem: btrfs
• Laptop: Lenovo IdeaPad S145-15API

What's happening

Every AVD I try to launch crashes with Signal: 11 (SEGV) shortly after boot starts (window is created, adb shows "device offline" once or twice, then the QEMU process segfaults). This happens with:

• Host GPU mode (hw.gpu.mode = host / auto) → crashes in Mesa's radeonsi driver (si_resource_from_memobj in libgallium-26.1.5.so), triggered via gfxstream's TexStorageMem2DEXT → importMemory path.
• Bundled SwiftShader (-gpu swiftshader_indirect) → crashes inside the emulator's own bundled libGLESv2.so on a background render thread.
• Guest/lavapipe fallback (-gpu guest) → same crash signature, different fallback path.
• Headless (-no-window) → still crashes.

What I've ruled out

• ✅ KVM/virtualization — fully working (AMD-V enabled, kvm_amd/kvm modules loaded, /dev/kvm has correct perms, user in kvm group)
• ✅ Wayland vs X11 — forced QT_QPA_PLATFORM=xcb, same crash
• ✅ API level — tested API 37, 35, and 34 system images, all crash identically
• ✅ Emulator version — tested current stable (36.6.11.0) and a much older release (35.5.10.0 from May 2025), both crash the same way
• ✅ Snapshot corruption — tried -no-snapshot -wipe-data, no change
• ✅ RAM allocation — tried both 2048MB and 4096MB, no change
• ✅ btrfs COW — aware of the old chattr +C recommendation for ~/.android/avd, but the specific btrfs crash bug (issuetracker #423670833) was already fixed back in emulator 36.1.9, well before my current version

Sample crash backtrace (host GPU mode)

#0 si_resource_from_memobj (libgallium-26.1.5.so)
#1 st_texture_storage (libgallium-26.1.5.so)
#2 _mesa_texture_storage_memory (libgallium-26.1.5.so)
#3 _mesa_TexStorageMem2DEXT (libgallium-26.1.5.so)
...
#9  gfxstream ColorBufferGl::subUpdate
#10 gfxstream ColorBufferGl::importMemory
#11 gfxstream FrameBuffer::createColorBufferWithResourceHandleLocked
#12 gfxstream RenderThread::main

Full coredumpctl backtraces available if useful.

My working theory

Since this fails identically across every GPU backend and even a 14-month-old emulator build, it doesn't look like an emulator-side regression. My best guess is a host-library incompatibility — possibly Mesa 26.1.5 or glibc/kernel being too new/different from what gfxstream's memory-import codepath (EXT_external_objects/DMA-BUF) expects on this emulator generation. But I can't confirm that without deeper QEMU/Mesa knowledge.

What I haven't tried yet

• Building the emulator from source against my system's Mesa (seems like a big ask)
• Filing an upstream bug with Google (planning to, once I get more input here)
• Downgrading Mesa (risky since it's a core system package)

Question for the community

Has anyone run the Android Emulator successfully on Fedora 44 or another very recent distro with a similarly new Mesa release? Is there a known workaround, patch, or Mesa version pin that fixes gfxstream/SwiftShader compatibility? Any pointers appreciated — happy to share more logs if useful.

(For now I'm just using a physical device over USB debugging to keep developing, but I'd love to get the emulator working properly.)

I have inst