Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leaking when using isolates with channels #250

Open
ffdb42 opened this issue Jan 26, 2023 · 5 comments
Open

Memory leaking when using isolates with channels #250

ffdb42 opened this issue Jan 26, 2023 · 5 comments

Comments

@ffdb42
Copy link

ffdb42 commented Jan 26, 2023

Hello.
My team uses this package to send files. While testing my project, I discovered the following thing: on all tested systems (Windows 10 & Ubuntu 22.04.1) there is a memory leak.
To be more precise, the application sends the file in parts in several isolates, its own IOWebSocketChannel is created for each isolate, logically, after sending all the parts, the connection closes, after which the isolate closes. But I've found that not all sockets are closed, some of them changes to CLOSE_WAIT state and do not exit it until the application is closed.
In my further research , I found the following: I wrote a small server application (HttpServer upgraded to WebSocket, which simply responds to incoming requests) and a client application in which I create 2 isolates, each of which creates an IOWebSocketChannel, one of which just sends a message once and then just listens to its stream, and the second sends a message, starts listening its stream (whose onDone and onError methods are never called), after which it closes its isolate (which in VSC debug mode then has the status "Paused on Pause"), after which it closes the socket itself (isolate closes only after this).
After such a sequence in Ubuntu via lsof, the second connection is displayed as ESTABLISHED, but if you close the server, it will switch to the CLOSE_WAIT state, any manipulations on the socket will not be available in the client application itself, because it seems to be closed. The client application itself does not terminate after all of this, although the isolates are displayed off and it is not waiting/listening to anything in the main isolate.
These manipulations are performed to simulate the behavior of my application and the final error looks similar to what we get in the project itself.

@pavlov061356
Copy link

I have a same issue too.

@SergeySor
Copy link

same problem

@osd3n
Copy link

osd3n commented Jan 27, 2023

Same issue

@Snowcrash5
Copy link

Same problem

@jeffscaturro-aka
Copy link

I wonder if what we're seeing in #281 is related to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants