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 leak #353

Open
PekingSpades opened this issue Nov 17, 2024 · 0 comments
Open

🐛Memory leak #353

PekingSpades opened this issue Nov 17, 2024 · 0 comments

Comments

@PekingSpades
Copy link

Precondition

  • Version number: latest version: { full: '2.0.5', major: 2, minor: 0, dot: 5 }
  • Browser: Chrome 130.0.6723.117

I modified the source code when I used it in my project. The main part that was modified was to determine when to use Blob. when my project is running under self-signed HTTPS and is on an intranet with no access to the internet, it will degrade to use the Blob scheme, as you would design it in your project. So, using Blob remains very common in my projects.

Anyway, if you downgrade to Blob, it triggers the bug.

Bug

Replication path: download large files using Blob. If you call the close() method multiple times, you can continue to trigger the download. This means that the data is still in memory.

Reason

Even if the caller no longer holds the object returned by streamsaver.createWriteStream, the memory referenced by the link created by the URL.createObjectURL method is still not freed.

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

1 participant