| Summary: | [GTK] imported/w3c/web-platform-tests/wasm/jsapi/constructor/instantiate-bad-imports.any.worker.html is a flaky failure | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Diego Pino <dpino> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | bugs-noreply, lmoura |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=211614 | ||
|
Description
Diego Pino
2020-02-28 02:37:12 PST
imported/w3c/web-platform-tests/wasm/webapi/instantiateStreaming-bad-imports.any.worker.html This test was updated and expected pass since r271993, but it's flaky with the same behavior. Maybe related bug211614 (another wasm worker flakiness). 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?
|