Fix wasm binary sends causing Blob receives and leaks#69
Open
matte1 wants to merge 1 commit into
Open
Conversation
matte1
force-pushed
the
matte1/patch_memory_leak
branch
from
fcf5488 to
e1bae72
Compare
The web backend was setting WebSocket.binaryType to Blob while sending WsMessage::Binary. That property only controls incoming message representation, so a binary send could force later binary receives through the Blob fallback instead of the intended ArrayBuffer path. Keep binary sends side-effect free, retain Blob FileReader callbacks only until loadend, and add wasm browser tests for both the binaryType regression and FileReader callback cleanup. Fix wasm binary sends causing Blob receives and leaks The web backend was setting WebSocket.binaryType to Blob while sending WsMessage::Binary. That property only controls incoming message representation, so a binary send could force later binary receives through the Blob fallback instead of the intended ArrayBuffer path. That fallback used FileReader with a forgotten closure per Blob message, so this could also leak memory over repeated binary receives. Keep binary sends side-effect free, retain Blob FileReader callbacks only until loadend, and add wasm browser tests for both the binaryType regression and FileReader callback cleanup.
matte1
force-pushed
the
matte1/patch_memory_leak
branch
from
e1bae72 to
869ae8b
Compare
Collaborator
|
Thanks, I'll take a look at it. |
Collaborator
|
Hi, I have a few upcoming deadlines and apologize for the delay but likely I won't be able to get to this until around July. Sorry for the inconvenience. I want to thank you for the PR and I do appreciate it and will try to review it as soon as I can. |
Author
|
No worries! I've patched this locally so I'm all good. I really enjoy all the (e)crates and appreciate y'alls work! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The web backend was setting WebSocket.binaryType to Blob while sending WsMessage::Binary. That property only controls incoming message representation, so a binary send could force later binary receives through the Blob fallback instead of the intended ArrayBuffer path.
That fallback used FileReader with a forgotten closure per Blob message, so this could also leak memory over repeated binary receives.
Keep binary sends side-effect free, retain Blob FileReader callbacks only until loadend, and add wasm browser tests for both the binaryType regression and FileReader callback cleanup.