Bug 240062 - Worker is terminated if it is unreachable from root even if it has handlers & document is active
Summary: Worker is terminated if it is unreachable from root even if it has handlers &...
Status: RESOLVED DUPLICATE of bug 244549
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: Safari 15
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-05-04 04:07 PDT by Takuo Kihira
Modified: 2023-01-01 23:45 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Takuo Kihira 2022-05-04 04:07:45 PDT
When running some WebWorkers (or single worker), sometimes suddenly workers stop without any messages or events.

https://dynamic-wasm-6128yfdg3-tkihira.vercel.app/worker-stall.html

I've made small reproducible example here. This URL runs 6 workers but on my Intel Mac & Safari 14, M1 Mac & Safari 15, and iOS 15.4 Mobile Safari some workers stopped suddenly and couldn't finish all workers.

This seems a threading problem, so if you can't reproduce it please retry it again.
Comment 1 Yusuke Suzuki 2022-05-05 20:21:47 PDT
I think Worker's DOM activity is not accounted as active when you missed a reference to workers. I think terminating that kind of workers are fine since we have no way to observe that, but SharedArrayBuffer adds a way to observe this termination side-effect.

You can workaround by adding workers reachable from the GC root.

```
globalThis.workers = [];

...

globalThis.workers.push(worker);
```
Comment 2 Yusuke Suzuki 2022-05-05 20:26:57 PDT
But maybe, I'm wrong, as worker has onmessage handler.
But it seems that workers are terminated.
@Chris, do you know when workers are terminated?
Comment 3 Yusuke Suzuki 2022-05-05 20:28:38 PDT
At least, manually clicking GC button made all stopped. So probably Worker's DOM activity would be wrongly calculated and worker is collected.
Comment 4 Takuo Kihira 2022-05-05 21:10:39 PDT
Thank you Yusuke, your workaround works on my environments well.


By the way, maybe the ArrayBuffer is not SharedArrayBuffer because I create it with

```
const memory = new WebAssembly.Memory({ initial: 1 });
```

and I don't specify `shared: true` option so I guess it could be a normal ArrayBuffer.
Comment 5 Radar WebKit Bug Importer 2022-05-11 04:08:14 PDT
<rdar://problem/93089061>
Comment 6 Ahmad Saleem 2022-05-28 18:22:09 PDT
I tried to reproduce this on Safari TP 146 and it seems to finish workers more reliably as compared to Stable Safari 15.4 but it is still intermittent (at least on first few tries but later finishing always) on some workers as they do get stuck.
Comment 7 Ahmad Saleem 2022-12-24 02:08:16 PST
Safari Technology Preview 160 is reliably able to close all thread, I tried it even with 80 threads.

Can someone else confirm that it is not an issue anymore?
Comment 8 youenn fablet 2023-01-01 23:45:21 PST
Duping to https://bugs.webkit.org/show_bug.cgi?id=244549 which was fixed a while ago.
@Takuo, please reopen if this is still reproducible in latest STP.

*** This bug has been marked as a duplicate of bug 244549 ***