[WASM] Browser tab crashes when dotnet-crypto-worker.js fails to connect to WebSocket

[simonrozsival]

Description

When I'm running the browser sample, occasionally the browser tab crashes reporting "Out of Memory".

It appears that the setup_proxy_console (debug.ts) called from the dotnet-crypto-worker.js modifies the console functions to send all logs over a websocket. The crash that I ran into occurs when the websocket connection fails and the onerror event logs this failure. This leads to an indirect infinite recursion bertween the local function send and the console.log replacement function and the browser tab runs out of memory in just a few seconds (the worker allocates over 3.5 GB of memory).

It seems this bug was introduced in #71693

Reproduction Steps

1. Build dotnet for Browser .\build.cmd mono+libs+packs -os Browser -c Release
2. Build the browser sample: .\dotnet.cmd build src\mono\sample\wasm\browser
3. Serve the output directory: .\dotnet.cmd serve -d:src\mono\sample\wasm\browser\bin\Release\AppBundle -h "Cross-Origin-Opener-Policy:same-origin" -h "Cross-Origin-Embedder-Policy:require-corp" -o -p:8000
4. Open http://localhost:8000 in Edge or Chrome
5. Open dev tools and refresh the page until you see WebSocket connection to 'ws://localhost:8000/console' failed in the console. It doesn't happen every time but it happens very often so you might need to refresh the page several times.
6. Switch to the Memory tab in the dev tools and watch the heap size of dotnet-crypto-worker.js grow rapidly
7. The browser tab will crash in 30-60 seconds

Expected behavior

The browser tab doesn't crash.

Actual behavior

The browser tab crashes.

Regression?

No response

Known Workarounds

No response

Configuration

• Current main branch (after Better error handling in SubtleCrypto workers #71693)
• Windows 11, x64
• Edge, Chrome
• I'm quite certain the problem is the infinite indirect recursion I described previously and therefore it should be independent of this configuration

Other information

No response

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

When I'm running the browser sample, occasionally the browser tab crashes reporting "Out of Memory".

It appears that the setup_proxy_console (debug.ts) called from the dotnet-crypto-worker.js modifies the console functions to send all logs over a websocket. The crash that I ran into occurs when the websocket connection fails and the onerror event logs this failure. This leads to an indirect infinite recursion bertween the local function send and the console.log replacement function and the browser tab runs out of memory in just a few seconds (the worker allocates over 3.5 GB of memory).

It seems this bug was introduced in #71693

Reproduction Steps

1. Build dotnet for Browser .\build.cmd mono+libs+packs -os Browser -c Release
2. Build the browser sample: .\dotnet.cmd build src\mono\sample\wasm\browser
3. Serve the output directory: .\dotnet.cmd serve -d:src\mono\sample\wasm\browser\bin\Release\AppBundle -h "Cross-Origin-Opener-Policy:same-origin" -h "Cross-Origin-Embedder-Policy:require-corp" -o -p:8000
4. Open http://localhost:8000 in Edge or Chrome
5. Open dev tools and refresh the page until you see WebSocket connection to 'ws://localhost:8000/console' failed in the console. It doesn't happen every time but it happens very often so you might need to refresh the page several times.
6. Switch to the Memory tab in the dev tools and watch the heap size of dotnet-crypto-worker.js grow rapidly
7. The browser tab will crash in 30-60 seconds

Expected behavior

The browser tab doesn't crash.

Actual behavior

The browser tab crashes.

Regression?

No response

Known Workarounds

No response

Configuration

• Current main branch (after Better error handling in SubtleCrypto workers #71693)
• Windows 11, x64
• Edge, Chrome
• I'm quite certain the problem is the infinite indirect recursion I described previously and therefore it should be independent of this configuration

Other information

No response

Author:	simonrozsival
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[pavelsavara]

I think that setup_proxy_console doesn't belong to production code.
It could be in separate ES6 module dynamically loaded by dotnet.js only when there is some configuration for it.
For sure should not send console log to localhost on random production machine without explicit config for it.