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.