IssueTracker

Adding 2 more thread dumps from another freeze. Again after switching branches and updating from git.

Thanks for the report. I believe that this is fixed in our development branch, and also in the branch that will become Ladybug Feature Drop Beta. If you could verify that this doesn't happen in a nightly build (from https://developer.android.com/studio/nightly) that would be helpful -- and of course if you can trigger this in a recent nightly build, that's would be very important information.

Sorry, I have not tried it on the nightly build, but since then I updated to Meerkat and I have not seen the freeze afterwards.

That's good to hear. I think that the fix (which for reference was https://github.com/JetBrains/intellij-community/commit/fe621544dd61a9af34d97958d3d823a7c3454a87) is effective for both beta and canary branches.

For the record I am also arranging for https://github.com/JetBrains/intellij-community/commit/a444c8a500883669fc05c7177f93b5b794fdd13b (same fix, different implementation class) to be included; it's probably inactive code in our configurations, but it might be possible to trigger nevertheless.

Thanks for the confirmation!

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Ladybug Feature Drop | 2024.2.2 RC 1
• Android Gradle Plugin 8.8.0-rc01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Ucfucuccj

Hyxucyccchccjch

Ycucuccjcn

Hola mundo

Hi folks, if UI freezes for you could you please put your emulator version here? You can find it in emulator's extended panel, Help > About. It should look like 34.1.12-11146273.

Mine is 34.1.11-11086671, freezing when docked inside Studio. I've been using it in a separate window since this issue and it hasn't frozen again. ("Frozen" as mentioned above: not updating until you manually switch between panels, then 1 new frame is shown).

Looks like our gRPC endpoint is not responding to new screenshot events from the renderer, causing studio not to update it's ui. It doesn't appear to be happening on TOT (in canary).

To be clear there are 2 possible causes we can investigate further:

• The emulator is producing frames, but Android Studio is not picking them up and displaying them.
• The emulator gRPC engine is not receiving frame events from the graphics engine, and therefor not producing frames.

Given that users report that the issue arose with a new emulator version, independently of studio, we should start with #2.

Ok, might have a local repro:

<--snip-->
13:40:09.646634 140674645149376 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.653825 140674645149376 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.653869 140674645149376 DEBUG   EmulatorService.cpp:1034           | Screenshot 612x1258 (xAxis: -4.7500019073486328), pixels: 2309688 in 7197 us.
13:40:09.653900 140674636756672 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.653979 140674636756672 DEBUG   EmulatorService.cpp:1009           | Allocation of string object. 0 < 2302248
13:40:09.654023 140675121952448 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.670349 140674636756672 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.670385 140674636756672 DEBUG   EmulatorService.cpp:1034           | Screenshot 611x1256 (xAxis: -4.7500019073486328), pixels: 2302248 in 12423 us.
13:40:09.670465 140675121952448 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:41:37.682536 140674628363968 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1 (4585x)
13:41:37.682596 140674628363968 DEBUG   LoggingInterceptor.cpp:84          | from: , start: 1701898897682243, rcvTime: 75, sndTime: 150, rcv: 24, snd: 24, rcv_cnt: 1, snd_cnt: 1, OK , /android.emulation.control.EmulatorController/getVmState() -> [state: RUNNING]
13:41:37.685011 140675121952448 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1

No new frames are being produced.. Let's see if we can attach a debugger.

Surprise #1: Multiple threads are waiting to register itself with the graphics engine..

thread #130, name = 'grpcpp_sync_ser'
android::base::ConditionVariable::wait(this=0x000055b207cae5d0, userLock=0x000055b207cae578) at ConditionVariable.h:146:9
    frame #5: 0x00007ff253c0157b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite(this=0x000055b207cae558) at MessageChannel.cpp:52:19
    frame #6: 0x000055b206d2e683 qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(void (*)(void*), void*) [inlined] android::base::MessageChannel<android::base::CallbackRegistry::ForwarderMessage, 64ul>::send(this=<unavailable>, msg=<unavailable>) at MessageChannel.h:122:28
    frame #7: 0x000055b206d2e67e qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(this=<unavailable>, messageAvailable=<unavailable>, opaque=<unavailable>) at CallbackRegistry.cpp:53:15
    frame #8: 0x000055b206e9734b qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(grpc::ServerContext*, android::emulation::control::ImageFormat const*, grpc::ServerWriter<android::emulation::control::Image>*) [inlined] std::__1::__unique_if<android::emulation::control::EventWaiter>::__unique_single std::__1::make_unique[abi:v170000]<android::emulation::control::EventWaiter, void (*)(void (*)(void*), void*), void (*)(void*)>(__args=<unavailable>, __args=<unavailable>) at unique_ptr.h:686:30
    frame #9: 0x000055b206e97326 qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(this=0x000055b20d9e2000, context=0x000055b236aeec10, request=0x000055b239a84870, writer=0x00007ff166c1bd88) at EmulatorService.cpp:717:23
thread #131, name = 'grpcpp_sync_ser'
    frame #0: 0x00007ff251ca3156 libc.so.6`__futex_abstimed_wait_common at futex-internal.c:57:12
    frame #1: 0x00007ff251ca3118 libc.so.6`__futex_abstimed_wait_common(futex_word=0x000055b207cae5f8, expected=0, clockid=<unavailable>, abstime=0x0000000000000000, private=<unavailable>, cancel=<unavailable>) at futex-internal.c:87:9
    frame #2: 0x00007ff251ca5818 libc.so.6`___pthread_cond_wait at pthread_cond_wait.c:503:10
    frame #3: 0x00007ff251ca5740 libc.so.6`___pthread_cond_wait(cond=0x000055b207cae5d0, mutex=0x000055b207cae578) at pthread_cond_wait.c:618:10
    frame #4: 0x00007ff253c0158b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite() [inlined] android::base::ConditionVariable::wait(this=0x000055b207cae5d0, userLock=0x000055b207cae578) at ConditionVariable.h:146:9
    frame #5: 0x00007ff253c0157b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite(this=0x000055b207cae558) at MessageChannel.cpp:52:19
    frame #6: 0x000055b206d2e683 qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(void (*)(void*), void*) [inlined] android::base::MessageChannel<android::base::CallbackRegistry::ForwarderMessage, 64ul>::send(this=<unavailable>, msg=<unavailable>) at MessageChannel.h:122:28
    frame #7: 0x000055b206d2e67e qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(this=<unavailable>, messageAvailable=<unavailable>, opaque=<unavailable>) at CallbackRegistry.cpp:53:15
    frame #8: 0x000055b206e9734b qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(grpc::ServerContext*, android::emulation::control::ImageFormat const*, grpc::ServerWriter<android::emulation::control::Image>*) [inlined] std::__1::__unique_if<android::emulation::control::EventWaiter>::__unique_single std::__1::make_unique[abi:v170000]<android::emulation::control::EventWaiter, void (*)(void (*)(void*), void*), void (*)(void*)>(__args=<unavailable>, __args=<unavailable>) at unique_ptr.h:686:30
    frame #9: 0x000055b206e97326 qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(this=0x000055b20d9e2000, context=0x000055b236af2e10, request=0x000055b20c672870, writer=0x00007ff16d04fd88) at EmulatorService.cpp:717:23
   thread #132, name = 'grpcpp_sync_ser'
    frame #0: 0x00007ff251ca3156 libc.so.6`__futex_abstimed_wait_common at futex-internal.c:57:12
    frame #1: 0x00007ff251ca3118 libc.so.6`__futex_abstimed_wait_common(futex_word=0x000055b207cae5f8, expected=0, clockid=<unavailable>, abstime=0x0000000000000000, private=<unavailable>, cancel=<unavailable>) at futex-internal.c:87:9
    frame #2: 0x00007ff251ca5818 libc.so.6`___pthread_cond_wait at pthread_cond_wait.c:503:10
    frame #3: 0x00007ff251ca5740 libc.so.6`___pthread_cond_wait(cond=0x000055b207cae5d0, mutex=0x000055b207cae578) at pthread_cond_wait.c:618:10
    frame #4: 0x00007ff253c0158b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite() [inlined] android::base::ConditionVariable::wait(this=0x000055b207cae5d0, userLock=0x000055b207cae578) at ConditionVariable.h:146:9
    frame #5: 0x00007ff253c0157b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite(this=0x000055b207cae558) at MessageChannel.cpp:52:19
    frame #6: 0x000055b206d2e683 qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(void (*)(void*), void*) [inlined] android::base::MessageChannel<android::base::CallbackRegistry::ForwarderMessage, 64ul>::send(this=<unavailable>, msg=<unavailable>) at MessageChannel.h:122:28
    frame #7: 0x000055b206d2e67e qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(this=<unavailable>, messageAvailable=<unavailable>, opaque=<unavailable>) at CallbackRegistry.cpp:53:15
    frame #8: 0x000055b206e9734b qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(grpc::ServerContext*, android::emulation::control::ImageFormat const*, grpc::ServerWriter<android::emulation::control::Image>*) [inlined] std::__1::__unique_if<android::emulation::control::EventWaiter>::__unique_single std::__1::make_unique[abi:v170000]<android::emulation::control::EventWaiter, void (*)(void (*)(void*), void*), void (*)(void*)>(__args=<unavailable>, __args=<unavailable>) at unique_ptr.h:686:30
    frame #9: 0x000055b206e97326 qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(this=0x000055b20d9e2000, context=0x000055b236aec810, request=0x000055b2399e8870, writer=0x00007ff1813fbd88) at EmulatorService.cpp:717:23
 

An unintentional side effect of the fix of b/286937712. The streamScreenshot API is registering an event listener for physical change events. This registration engine is using the CallbackRegistry, this thing has the unintended side effect that registration is only processed when the invokeCallbacks method is called. This is usually not a problem when using the GpuEngine as we receive frequent updates.

This is not the case for physical events. Things get unblocked as soon as a sensor state change happens.

Just wanted to add I've been experiencing this as well on an M1 Mac. For me running the app in release mode works fine. If you build and run in Debug and have the debugger attached, then the frames are not updating.

However this only happens in Canary:

Android Studio Iguana | 2023.2.1 Canary 17
Build #AI-232.10227.8.2321.11191411, built on December 7, 2023
Runtime version: 17.0.9+0-17.0.9b1087.7-11185874 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.2
GC: G1 Young Generation, G1 Old Generation
Memory: 3072M
Cores: 10
Metal Rendering is ON
Registry:
    debugger.new.tool.window.layout=true
    ide.instant.shutdown=false
    ide.experimental.ui=true

If I run the same exact emulator version 34.1.13-11169323, in current Stable:

Android Studio Hedgehog | 2023.1.1
Build #AI-231.9392.1.2311.11076708, built on November 9, 2023
Runtime version: 17.0.7+0-17.0.7b1000.6-10550314 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.2
GC: G1 Young Generation, G1 Old Generation
Memory: 3072M
Cores: 10
Metal Rendering is ON
Registry:
    external.system.auto.import.disabled=true
    debugger.new.tool.window.layout=true
    ide.text.editor.with.preview.show.floating.toolbar=false
    ide.instant.shutdown=false
    ide.experimental.ui=true

It does not have this issue.

Worth noting that the pop-out mode doesn't affect this.

Fix is in with https://android-review.git.corp.google.com/c/platform/external/qemu/+/2863491

https://android-review.git.corp.google.com/c/platform/external/qemu/+/2874534

what version of emulator should this be in?

Still seeing this issue with 34.1.15-11228956 in AS Hedgehog 2023.1.1 patch 1

FWIW Not seeing this issue anymore in latest canaries/beta.

I'm having this issue still.

Android Studio Iguana | 2023.2.1 Build #AI-232.10227.8.2321.11479570, built on February 22, 2024 Runtime version: 17.0.9+0--11185874 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Windows 11.0

Android emulator version 34.1.18.0

This should be fixed in 34.1.19, please update and let us know.

Note

From now till end of Feb 2024, we are migrating to using a separate task item to track postmortem status, instead of using the original fixed bug. You may run into unexpected issues as we iron out the wrinkles in the automated workflow. Any questions or feedback, please email: android-hygiene-autobug-filer@.

Thank you for your patience and support.