Android emulator encounters segmentation fault on opening Aurora Store

raxod502 · 2026-03-07 02:07:08

I previously ran Pop!_OS 22.04, and now that I've migrated to Arch (and, in the process, upgraded a lot of software) I'm finding that the Android emulator encounters a segmentation fault after I log in to Aurora Store. This occurs both with the proprietary Google emulator and image (system-images;android-36;default;x86_64) as well as the GrapheneOS emulator release 2026021200 which I've compiled from source, both of which previously worked on the same hardware to my knowledge.

I made a forum post with the GrapheneOS folks (https://discuss.grapheneos.org/d/32477- … rora-store) but received no response. I also filed a ticket against Aurora Store (https://gitlab.com/AuroraOSS/AuroraStor … items/1493) where it was suggested to test the generic (Google) emulator, and I found that it had the same problem so this is probably not specific to GrapheneOS.

The GOS forum post includes adb and emulator logs in case those are helpful.

I did some research on my own and found a lot of people saying that the emulator is broken on Wayland. However, while adding QT_QPA_PLATFORM=xcb removed a warning, it did not change the behavior. I also saw it suggested to change to software graphics, by adding -gpu software, but this had no effect besides removing another warning. I suspect that the emulator was already automatically falling back to XWayland and software graphics, and that the real problem is something not related to either of those two.

Anyone have ideas on if there are extra steps to getting Android emulation running on modern Arch?

Edit: This is on a System 76 Oryx Pro 6 with Intel + NVIDIA graphics card (using nvidia-utils). I tested on a Framework 13 with Intel graphics card only (using vulkan-intel), and found that the same crash is not occurring. The systems are both running Arch (GNOME, Wayland) and are generally configured pretty much the same.

Last edited by raxod502 (2026-03-07 02:45:49)

seth · 2026-03-07 10:24:31

You'll have to provide the backtrace, https://wiki.archlinux.org/title/Core_d … _core_dump
Ideally don't strip but enable the debug flag when compiling yourself (so it's not just a bunch of stack positions)

raxod502 · 2026-03-08 00:14:14

Cool, I compiled a debug build from source. It was rather complicated, especially as it turns out that by default they enable a component called ASAN that causes the emulator to crash immediately on startup no matter what, and even when disabled at runtime still manages to inhibit the creation of core dumps. Also, as far as I can tell the build process is completely undocumented so you have to squint at the source code to find out likely scripts and options to use.

Here are the steps I used to compile and run:

repo init -u https://android.googlesource.com/platform/manifest -b emu-36-1-release
repo sync -j8 --force-sync
cd external/qemu
./android/rebuild.sh --config debug --cmake_option OPTION_ASAN_IN_DEBUG=FALSE
QT_QPA_PLATFORM=xcb ./objs/distribution/emulator -avd android16 -no-metrics -gpu swiftshader_indirect

Upon inspecting the core dump with gdb, I got the following: https://files.intuitiveexplanations.com … TLTBIu.txt

(I omitted "No symbol table info available", which occurred very frequently in the gdb output. Maybe some debugging symbols were still not included despite the build being in debug mode?)

seth · 2026-03-08 08:45:07

Because

which I've compiled from source

I thought you'd be already doing that anyway?

Maybe some debugging symbols were still not included despite the build being in debug mode?)

https://wiki.archlinux.org/title/Debuginfod

https://files.intuitiveexplanations.com … TLTBIu.txt
Which one was the active thread? (You get some status report when gdb intercepts a signal and before dumping the backtrace)
I assume there're lines missing from thread #1 (the main thread at the bottom of the file has only two anonymous stack positions)

raxod502 · Yesterday 00:47:06

I thought you'd be already doing that anyway?

I only learned later on that the Android build system is really weird and even if you compile from source, some sub-components of it such as the emulator are just checked into the repository as binaries, and you have to do additional steps to actually compile those from source too.

Which one was the active thread?

It looks like thread 1:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055b55390833a in ?? ()
[Current thread is 1 (Thread 0x7f56475026c0 (LWP 143565))]

I've generated a new core dump and made sure that debuginfod was enabled, however it does still show a large number of anonymous stack locations: https://files.intuitiveexplanations.com … taSCHM.txt

seth · Yesterday 09:53:09

Thread 1 (Thread 0x7f56475026c0 (LWP 143565)):
#0  0x000055b55390833a in ?? ()
No symbol table info available.
#1  0x0000000000000000 in ?? ()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No symbol table info available.

Stack corruption \o/

Thread 34 (LWP 143344):
#0  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x0
…
Thread 165 (Thread 0x7f564bd0b6c0 (LWP 143556)):
#0  0x000055b553907572 in ?? ()
No symbol table info available.
#1  0x0000000000000000 in ?? ()
No symbol table info available.

Everything else is somehow waiting fro futexes or starting threads (in webrtc, fitting the aurora store pattern?) - and I suspect the heavy multithreading is the problem here…

with Intel + NVIDIA graphics card (using nvidia-utils)

Can you test software rendering, https://wiki.archlinux.org/title/NVIDIA … oftware_GL (also export LIBGL_ALWAYS_SOFTWARE=1 to cover all chips)

raxod502 · Today 00:03:10

Tried again with

LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json QT_QPA_PLATFORM=xcb ./objs/distribution/emulator/emulator -avd android16 -no-metrics -gpu swiftshader_indirect

and unfortunately same result, updated core dump: https://files.intuitiveexplanations.com … Jj8b8q.log

Arch Linux

#1 2026-03-07 02:07:08

Android emulator encounters segmentation fault on opening Aurora Store

#2 2026-03-07 10:24:31

Re: Android emulator encounters segmentation fault on opening Aurora Store

#3 2026-03-08 00:14:14

Re: Android emulator encounters segmentation fault on opening Aurora Store

#4 2026-03-08 08:45:07

Re: Android emulator encounters segmentation fault on opening Aurora Store

#5 Yesterday 00:47:06

Re: Android emulator encounters segmentation fault on opening Aurora Store

#6 Yesterday 09:53:09

Re: Android emulator encounters segmentation fault on opening Aurora Store

#7 Today 00:03:10

Re: Android emulator encounters segmentation fault on opening Aurora Store

Board footer