IssueTracker

This bug should go to the emulator team. However, I do not have permission to file bug against them yet.

Thank you for reporting this. I think we have a bad race condition in RecurrentTask. When a callback fires, the QEMUTimer is empty (see QEMU/util/qemu-timer.c and I don't see anything conveying the information that the callback is running (please note the call before cb(opaque) is unlock):

        /* remove timer from the list before calling the callback */
        timer_list->active_timers = ts->next;
        ts->next = NULL;
        ts->expire_time = -1;
        cb = ts->cb;
        opaque = ts->opaque;

        /* run the callback (the timer list can be modified) */
        qemu_mutex_unlock(&timer_list->active_timers_lock);
        cb(opaque);
        qemu_mutex_lock(&timer_list->active_timers_lock);

and timer_del_locked simply removes the QEMUTimer instance from the active_timers list. I am not sure how to avoid race conditions here. Consider this:

1:  void myCallback(void* arg) {
2:
3:      someCall();
4:
5:  }

1. The control enters into myCallback and the thread is preempted before the function had a chance making any side effect (line 2 here).
2. ˜RecurrentTask is called on a separate thread.
3. Since myCallback did not write anywhere that it is busy ˜RecurrentTask proceeds destroying the state myCallback is about to access.
4. myCallback wakes and proceeds accessing already destroyed data.

Either I am missing something or this API is incomplete.

I talked to QEMU, they confirmed the API is indeed incomplete:

https://lore.kernel.org/all/CABgObfaBjneGy__o_aABdm+60wsg=rxLmgZLthwCoezwnH34ZQ@mail.gmail.com/

I sent a patch to fix this on the QEMU side, once it lands, I will fix our side.

Just a note - we recompiled 33.1.24 by simply taking out the ifdefs in IpAddress::toString() and by turning on gfxstream and got no linker issues (according to the comment that was why the ifdef guards were there in the first place) and proxy seems to work.

If there is no progress on this can anyone from the google team advise how to properly build with gfxstream on? What we did was take 33.1.24 and remove the ifdef in the snipper above and then turn on the gfxstream cmake option, but it seems that that causes a weird build - we get ""Your GPU drivers may have a bug" which as far as i can see should not be there since the getGpuInfoListNative method in hardware/google/gfxstream/gl-host-common/opengl/NativeGpuInfo_linux.cpp doesn't even scan for gpus? So we are clearly somehow building it wrong, any advice would be appreciated as long as we cannot use the stock emulator with the proxy feature working.

Hello, this is impacting us greatly. Please fix this asap. Thank you.

I have confirmed that the issue is only happening on gfxstream due to some mingw build issue. https://android-review.git.corp.google.com/c/platform/external/qemu/+/1190020/24

Since the review link is not public, could you confirm that removing the ifdef is a legitimate fix (and the random rare crashes we we are seeing with removing the ifdef and building with gfxstream is something else) or are there other changes that need to be done?

RE#10 Thank you for pointing that out. Removing the ifdef is a legitmate fix. The random crash is interesting but I doubt it has to with removing ifdef. Previously the ifdef guard was there probably because we used to have migw windows target but I don't think it's there anymore.

My fix is landed in CL and the next canary and release branch will include the fix.