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

Fix memory leak bug when re-using abortSignal (#2160) #2161

Closed
wants to merge 1 commit into from

Conversation

jopemachine
Copy link
Contributor

@jopemachine jopemachine commented Oct 10, 2022

Checklist

  • I have read the documentation.
  • I have included a pull request description of my changes.
  • I have included some tests.
  • If it's a new feature, I have included documentation updates in both the README and the types.

This PR trying to fix #2160. (WIP)
abortHandler of request instance will be removed when the response end or error, abort.

@jopemachine jopemachine marked this pull request as draft October 10, 2022 12:10
@@ -545,6 +544,10 @@ export default class Request extends Duplex implements RequestEvents<Request> {
return this;
}

private abortHandler(): void {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit

Suggested change
private abortHandler(): void {
private _abortHandler(): void {

@@ -664,6 +667,7 @@ export default class Request extends Duplex implements RequestEvents<Request> {
response.once('end', () => {
this._responseSize = this._downloadedSize;
this.emit('downloadProgress', this.downloadProgress);
this.removeListener('abort', this.abortHandler);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be called on the signal instead

@@ -674,6 +678,7 @@ export default class Request extends Duplex implements RequestEvents<Request> {
response.destroy();

this._beforeError(new ReadError(error, this));
this.removeListener('abort', this.abortHandler);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

response is not guaranteed, but request is. However listening on error request event is also incorrect because of retries. I'd suggest to move this to _destroy.

@marcelmeulemans
Copy link
Contributor

There is a possible fix here if it helps: marcelmeulemans@1bc4982

@jopemachine
Copy link
Contributor Author

There is a possible fix here if it helps: marcelmeulemans@1bc4982

Great! I think this implementation fix #2160 correctly.
I checked this implementation removes the memory leak bug in the submited code.

스크린샷 2022-10-11 오전 8 22 30

I will close this PR due to wrong implementation, and there comes out possible fix now.

@marcelmeulemans
Copy link
Contributor

Would you like me to open a PR for that fix? If so any ideas for how to write a unit test for the issue?

@jopemachine
Copy link
Contributor Author

jopemachine commented Oct 10, 2022

Would you like me to open a PR for that fix? If so any ideas for how to write a unit test for the issue?

About unit test, I think you better ask for the question to this repository's maintainers.
By the way, I think maybe we could have better code using the ? operator like below.

jopemachine@6d1223b

@marcelmeulemans
Copy link
Contributor

FYI #2162

I considered using the ? operator as you suggested but it seemed a shame to do the same nil check multiple times and the if block kinda nicely groups all abort signal code together i.m.o. If you feel strongly about it please a a comment and I will update.

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

Successfully merging this pull request may close these issues.

Resource leak when (re-)using an abort signal
3 participants