Skip to content

smart subtransport: don't free the url when resetting the stream#4911

Closed
carlosmn wants to merge 1 commit into
masterfrom
cmn/reset-dont-free-url
Closed

smart subtransport: don't free the url when resetting the stream#4911
carlosmn wants to merge 1 commit into
masterfrom
cmn/reset-dont-free-url

Conversation

@carlosmn

Copy link
Copy Markdown
Member

We reset the stream in the RPC (HTTP) case constantly and then pass the url
field to the action method for the transport to perform their action.

A transport would thus get NULL for the url and if it does use it, it might
crash or at least return an error making it impossible for it to work.

The transports that come with libgit2 keep their own copy of the url and thus
this issue was not noticed.


This should resolve the issue that cargo is experiencing with the changes in #4732 while still plugging the leak by freeing the URL before we set it anew when connecting.

/cc @grahamc @alexcrichton rust-lang/cargo#6365

We reset the stream in the RPC (HTTP) case constantly and then pass the url
field to the action method for the transport to perform their action.

A transport would thus get `NULL` for the url and if it does use it, it might
crash or at least return an error making it impossible for it to work.

The transports that come with libgit2 keep their own copy of the url and thus
this issue was not noticed.
@alexcrichton

Copy link
Copy Markdown
Contributor

Oh awesome, thanks for the fix!

@ethomson

Copy link
Copy Markdown
Member

Didn't #4880 fix this? We just need to backport that fix, no?

@carlosmn

Copy link
Copy Markdown
Member Author

Oh, I missed that. That would solve it yes, though the only times when we pass true is when we're about to free the URL anyway during close, or when we're setting the URL.

It seems more confusing to do it that way than leave the freeing to the caller.

@ethomson

Copy link
Copy Markdown
Member

I don't know that I agree, the goal of the reset function is to give us the original state back. In any case, I think we'd need to do this free in the close function as well if we're going to remove this functionality. Closing this since I think that keeping the common reset logic in a single place might make more sense, but obvs there's a lot of ways to do it so we can reevaluate if you want.

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