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: TestDialFailPDLeak failure #6553

Closed
alberts opened this issue Oct 9, 2013 · 15 comments

Comments

Projects
None yet
6 participants
@alberts
Copy link
Contributor

commented Oct 9, 2013

What steps will reproduce the problem?

On our big server, running the tests with:

go test -v -cpu 1,2,4 -timeout=60m std

What do you see instead?

=== RUN TestDialFailPDLeak
--- PASS: TestDialFailPDLeak (0.09 seconds)
...

=== RUN TestDialFailPDLeak-2
--- PASS: TestDialFailPDLeak-2 (0.04 seconds)
...

=== RUN TestDialFailPDLeak-4
--- FAIL: TestDialFailPDLeak-4 (0.02 seconds)
dial_test.go:475: detected possible memory leak in runtime

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

linux

Which version are you using?  (run 'go version')

go version devel +f543981e96da Tue Oct 08 16:16:24 2013 -0700 linux/amd64

Please provide any additional information below.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2013

Comment 1:

Owner changed to @ianlancetaylor.

Status changed to Started.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2013

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2013

Comment 3:

This issue was closed by revision 649fc25.

Status changed to Fixed.

@alberts

This comment has been minimized.

Copy link
Contributor Author

commented Oct 15, 2013

Comment 4:

This test still seems flaky, as reported here:
https://golang.org/cl/14526048#msg6
@mikioh

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2013

Comment 5:

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2013

@gopherbot

This comment has been minimized.

Copy link

commented Apr 9, 2014

Comment 10:

CL https://golang.org/cl/14742043 references this issue.
@josharian

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2014

Comment 11:

Applying https://golang.org/cl/90370043 and running with -test.cpu=2 makes the
test fail reliably on my system, instead of intermittently.
I don't see how to make the test as written work. Consider the following (after applying
CL 90370043):
$ go test -c net
$ GODEBUG=allocfreetrace=1 ./net.test -test.cpu=2 -test.run=TestDialFailPDLeak -test.v
2> aft.log
$ grep "single object" aft.log | awk -F "," '{print $3}' | sort | uniq -c | sort -n -r |
head
2523  single object of net.TCPAddr)
2503  single object of net.OpError)
2500  single object of syscall.SockaddrInet4)
2500  single object of struct { F uintptr; A0 *sync.WaitGroup; A1 **net.Dialer; A2
**testing.T })
2500  single object of net.netFD)
 689  single object)
  43  single object of errors.errorString)
  26  single object of net.Interface)
  22  single object of syscall.SockaddrDatalink)
  22  single object of syscall.InterfaceMessage)
Every pass through the loop allocates a net.TCPAddr, a net.OpError, a
syscall.SockaddrInet4, a closure, and a net.netFD. The test as written assumes that
nothing in the loop allocates, and thus any allocs must be due to allocPollDesc. I'm not
sure how to alter the test to fix this, aside perhaps from instrumenting allocPollDesc
directly.
Suggestions?
@mikioh

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2014

Comment 12:

I abandoned CL 14742043 because it's been ignored for a few months and this is a subtle
issue. I think that checking runtime.MemStats.OtherSys might be better; see changeset:
18019:cbacca9a8c67; poll descriptor pool stays at the non-GC region.
@josharian

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2014

Comment 13:

Naively switching to runtime.MemStats.OtherSys didn't do the trick. Surprisingly, there
were no OtherSys allocs at all during the first few loops, which makes me wonder whether
runtime.MemStats.OtherSys is working correctly.
I'd be curious to see CL 14742043, if it is still floating around somewhere on your
machine. (I'm just tired of ignoring this test failure when running other net tests.)
@gopherbot

This comment has been minimized.

Copy link

commented May 8, 2014

Comment 14:

CL https://golang.org/cl/98080043 mentions this issue.
@mikioh

This comment has been minimized.

Copy link
Contributor

commented May 9, 2014

Comment 15:

This issue was closed by revision f40f0b2.

Status changed to Fixed.

@alberts alberts added fixed labels May 9, 2014

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.