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

net: TestUnixAndUnixpacketServer flaky on linux #31423

Open
bcmills opened this issue Apr 11, 2019 · 4 comments

Comments

@bcmills
Copy link
Member

commented Apr 11, 2019

https://build.golang.org/log/09fce21c31d8c4435fb99a4f7c0e8a1bb2bf900f and
https://build.golang.org/log/faa4560674d8e7d406b7031bfe985db237b9860a:

--- FAIL: TestUnixAndUnixpacketServer (0.00s)
    server_test.go:197: #3: EOF
FAIL
FAIL	net	8.796s

See previously #13205 (CC @bradfitz).

@bcmills bcmills added this to the Go1.13 milestone Apr 11, 2019

@bcmills bcmills changed the title net: TestUnixAndUnixpacketServer flake on linux-386-clang builder net: TestUnixAndUnixpacketServer flaky on linux-386-clang builder Apr 11, 2019

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

/cc @mikioh

@bcmills bcmills changed the title net: TestUnixAndUnixpacketServer flaky on linux-386-clang builder net: TestUnixAndUnixpacketServer flaky on linux May 30, 2019

@bcmills

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

@bcmills

This comment has been minimized.

Copy link
Member Author

commented Jun 21, 2019

@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019

@bigmikes

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

TestUnixAndUnixpacketServer makes use of transponder function for the echo server. After some investigation I noticed that the test become stable if connection is not closed. I basically commented the below defer c.Close() line.

return
}
defer c.Close()
network := ln.Addr().Network()

I am not sure why this is happening. In theory the Close should take care of flushing all the data of socket before actually closing it.

Is it possible that for really unlucky cases the connection gets closed before the client is able to read the data?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.