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

net/rpc: race condition in Server.ServeCodec #17239

Closed
willfaught opened this Issue Sep 26, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@willfaught
Contributor

willfaught commented Sep 26, 2016

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

It was 1.6 (on a work computer I don't have access to anymore).

What operating system and processor architecture are you using (go env)?

It was Mac OS 10.11 (on a work computer I don't have access to anymore).

What did you do?

There's a race condition in Server.ServeCodec, where the connection is closed without waiting for all calls to finish:

477         go service.call(server, sending, mtype, req, argv, replyv, codec)
478     }
479     codec.Close()

In this code, the go statement is executed in a loop, and then the codec is closed immediately after the loop ends, which in the case of the jsonrpc codec closes the connection used by the calls before they can finish, resulting in errors.

@quentinmit

This comment has been minimized.

Show comment
Hide comment
@quentinmit

quentinmit Oct 4, 2016

Contributor

/cc @robpike @rsc @adg

I think the intent here is for the loop to block again when it loops on readRequest.

How are you managing to exit the loop?

We could of course fix this by adding a sync.WaitGroup to track the outstanding RPCs, but then you would not be able to tell from the RPC handler when the connection is closed and you should abort.

Contributor

quentinmit commented Oct 4, 2016

/cc @robpike @rsc @adg

I think the intent here is for the loop to block again when it loops on readRequest.

How are you managing to exit the loop?

We could of course fix this by adding a sync.WaitGroup to track the outstanding RPCs, but then you would not be able to tell from the RPC handler when the connection is closed and you should abort.

@quentinmit quentinmit added this to the Go1.8Maybe milestone Oct 4, 2016

@robpike

This comment has been minimized.

Show comment
Hide comment
@robpike

robpike Oct 4, 2016

Contributor

If this is related to #5792, as I think it is, it's really hard to fix. The read half is relatively easy but the write half is not. See also #16844, which was introduced partly in response to this problem.

Contributor

robpike commented Oct 4, 2016

If this is related to #5792, as I think it is, it's really hard to fix. The read half is relatively easy but the write half is not. See also #16844, which was introduced partly in response to this problem.

@willfaught

This comment has been minimized.

Show comment
Hide comment
@willfaught

willfaught Oct 5, 2016

Contributor

How are you managing to exit the loop?

By closing the connection to shut down the server gracefully.

Contributor

willfaught commented Oct 5, 2016

How are you managing to exit the loop?

By closing the connection to shut down the server gracefully.

@rsc rsc self-assigned this Oct 6, 2016

@rsc rsc modified the milestones: Go1.9, Go1.8Maybe Nov 2, 2016

@bradfitz bradfitz modified the milestones: Go1.10, Go1.9 Jun 7, 2017

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Nov 22, 2017

Contributor

CL sent.

Contributor

rsc commented Nov 22, 2017

CL sent.

@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Nov 22, 2017

Change https://golang.org/cl/79515 mentions this issue: net/rpc: wait for responses to be written before closing Codec

gopherbot commented Nov 22, 2017

Change https://golang.org/cl/79515 mentions this issue: net/rpc: wait for responses to be written before closing Codec

@willfaught

This comment has been minimized.

Show comment
Hide comment
@willfaught

willfaught Nov 22, 2017

Contributor

Awesome! Thanks @rsc!

Contributor

willfaught commented Nov 22, 2017

Awesome! Thanks @rsc!

@gopherbot gopherbot closed this in 4f6d8a5 Nov 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment