Skip to content

Conversation

@normanmaurer
Copy link
Member

Motivation:

We should guard against the sitation where we can't map the stream. While this should never happen its better to be safe than sorry.

Modifications:

  • Ensure the required Http2FrameStream can be found and only after that try to construct the specific frame.
  • Release ByteBuffer when DefaultHttp2DataFrame constructor throws

Result:

Fix possible buffer leaks

Motivation:

We should guard against the sitation where we can't map the stream. While this should never happen its better to be safe than sorry.

Modifications:

- Ensure the required Http2FrameStream can be found and only after that try to construct the specific frame.
- Release ByteBuffer when DefaultHttp2DataFrame constructor throws

Result:

Fix possible buffer leaks
@normanmaurer
Copy link
Member Author

Noticed while working on something else

Copy link
Contributor

@franz1981 franz1981 left a comment

Choose a reason for hiding this comment

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

good catch!

Copy link
Contributor

@bryce-anderson bryce-anderson left a comment

Choose a reason for hiding this comment

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

I'm not strongly opinionated about it, but I like the elements of this PR that require acquiring the stream as the first operation but I liked the previous behavior of making any .retain() call the last thing we did before forwarding the frame.

Comment on lines -665 to +676
onHttp2Frame(ctx, new DefaultHttp2GoAwayFrame(lastStreamId, errorCode, debugData).retain());
onHttp2Frame(ctx, new DefaultHttp2GoAwayFrame(lastStreamId, errorCode, debugData.retain()));
Copy link
Contributor

Choose a reason for hiding this comment

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

As noted above, I think the pattern of building the frame and then once we're ready to forward it calling .retain() was better as it didn't retain until everything else was done. With this change if the constructor throws (perhaps a constructor assert added in the future) we leak the debugData buffer.

Copy link
Member Author

Choose a reason for hiding this comment

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

I disagree because it is kind of a miss-use of the API. We don't want to retain the frame we really want to retain the payload. And we need to do this before calling the constructor as in theory it might call release on it.

Copy link
Contributor

Choose a reason for hiding this comment

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

It sounds like when we pass the content into the frame constructor we're delegating ownership of it, otherwise the constructor has no right to release the buffer etc, very similar to the notion of move in C++ and Rust. That makes a lot of sense to me.
Maybe we should make the DefaultHttp2DataFrame constructor (as far as I can tell it's the only one that may throw right now) release the content if it's going to throw. That would remove the odd noise in onDataRead(..).

@normanmaurer normanmaurer merged commit 1cfd3a6 into 4.1 Jan 31, 2025
17 checks passed
@normanmaurer normanmaurer deleted the http2_possible_leak branch January 31, 2025 07:45
normanmaurer added a commit that referenced this pull request Jan 31, 2025
Motivation:

We should guard against the sitation where we can't map the stream.
While this should never happen its better to be safe than sorry.

Modifications:

- Ensure the required Http2FrameStream can be found and only after that
try to construct the specific frame.
- Release ByteBuffer when DefaultHttp2DataFrame constructor throws

Result:

Fix possible buffer leaks
normanmaurer added a commit that referenced this pull request Jan 31, 2025
Motivation:

We should guard against the sitation where we can't map the stream.
While this should never happen its better to be safe than sorry.

Modifications:

- Ensure the required Http2FrameStream can be found and only after that
try to construct the specific frame.
- Release ByteBuffer when DefaultHttp2DataFrame constructor throws

Result:

Fix possible buffer leaks
normanmaurer added a commit that referenced this pull request Jan 31, 2025
Motivation:

We should guard against the sitation where we can't map the stream.
While this should never happen its better to be safe than sorry.

Modifications:

- Ensure the required Http2FrameStream can be found and only after that
try to construct the specific frame.
- Release ByteBuffer when DefaultHttp2DataFrame constructor throws

Result:

Fix possible buffer leaks
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.

4 participants