[Webkit-unassigned] [Bug 208368] [GTK] imported/w3c/web-platform-tests/wasm/jsapi/constructor/instantiate-bad-imports.any.worker.html is a flaky failure

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=208368

Lauro Moura <lmoura at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs-noreply at webkitgtk.org

--- Comment #2 from Lauro Moura <lmoura at igalia.com> ---
After some investigation, this seems to be some issue related to timer callbacks being called from different run loops (or something like that).

The Wasm.instantiate (JSWebAssembly.cpp::instantiate() call compiles the code asynchronously, scheduling a timer job to resolve the promise as soon as possible (through vm.deferredWorkTimer->scheduleWorkSoon(...).

Normal flow:

Scheduling: 
1 DeferredWorkTimer.cpp::scheduleWorkSoon()
  1.1 No scheduled work. Timer scheduled immediately through JSRunLoopTimer.cpp::Manager.scheduleTimer()
    1.1.1 scheduleTimer() then associate this timer with the PerVMData for the current VM/runLoop() of this timer.
    1.1.2 schedule a oneShot to trigger the timer through the PerVMData manager.

Firing timer:

1 JSRunLoopTimer::Manager::timerDidFire()
  1.1 Iterate through PerVMData items, skipping those from a different RunLoop than RunLoop::current()
  1.2 For each VM, take the timers that should be fired and trigger them.

Back to the test, in a normal run, the timerDidFire() call immediately after scheduling is always called from the same RunLoop that registered it and everything follows happily.

When the timeout occurs - in comparison to a clean run - the timerDidFire() seems to be called from a different RunLoop::current() than the one when the timer callback was scheduled, so the instantiate() timers are being ignored by the runloop check.

Not sure why this is happending or what would be the proper fix.

As this does not seems to be something wasm-specific, this could be the cause of other worker tests flakiness, no?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210331/27261052/attachment-0001.htm>