net/rpc or encoding/gob: Confusing behavior, deadlock or hang with what looks like valid code

[gopherbot]

This was brought up by jgr on IRC. I can't come up with an explanation for this
behavior. Apologies if there's a mistake in the code.

This code: http://play.golang.org/p/U4elciYqmL
triggers the deadlock detector on playground, hangs on Linux (go tip 5439c77d4acb).
Exporting "msg" as "Msg" makes it work. `type Reply struct{}` makes
it work.

I don't see how different message contents would trigger deadlock/hang. I expected to
just see a "main.Reply{}" output for the non-exported case.

[gopherbot]

Comment 1:

Wessie on IRC pointer out that net/rpc ignores errors from codec.WriteResponse.
http://golang.org/src/pkg/net/rpc/server.go#L360
http://play.golang.org/p/D1sd-llvdm
So perhaps this is a case of gob refusing to write anything, while the receiver is
expecting to see something, and nobody catching that error.

[gopherbot]

Comment 2:

*pointed out

[gopherbot]

Comment 3:

This is probably a duplicate of https://golang.org/issue/7689

[gopherbot]

Comment 4:

Just to say this more explicitly, it looks the like the next async net/rpc response
arriving will be decoded as the body of the of the previous one, as the sending send did
not send any data. This will lead to Bad Things(tm).

[ianlancetaylor]

Comment 5:

Labels changed: added repo-main, release-go1.4.

[robpike]

Comment 6:

It now gives:
2014/10/03 14:55:09 rpc: gob error encoding body: gob: type main.Reply has no exported
fields
panic: reading body EOF
Nice enough I might use it as a test for net/rpc.

Status changed to Duplicate.

Merged into issue #7689.

[gopherbot]

Comment 7:

CL https://golang.org/cl/151370043 mentions this issue.