container/list: Remove of invalid Element after Init / reset leads to negative Len

[gobwas]

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

$ go version
go version go1.14.2 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output

$ go env
GOHOSTARCH="amd64"
GOHOSTOS="darwin"

What did you do?

var l list.List
el := l.PushBack(42)
l = list.List{} // Reset the list.
l.Remove(el)
fmt.Println(l.Len())

What did you expect to see?

0

What did you see instead?

-1

[lsytj0413]

Because the another assign l = list.List{} Never change the address of l, you can print the memory address of l with:

	fmt.Printf("%p\n", &l)
	el := l.PushBack(42)
	l = list.List{} // Reset the list.
	fmt.Printf("%p\n", &l)

[lsytj0413]

Maybe list.List should disable copy with

go/src/sync/cond.go

Line 94 in c2eba53

type noCopy struct{}

[gobwas]

@lsytj0413 Yes, I know why it happens, thank you. Anyway, the comment about List tells that The zero value for List is an empty list ready to use..

[lsytj0413]

@lsytj0413 Yes, I know why it happens, thank you :) Anyway, the comment about List tells that The zero value for List is an empty list ready to use..

It's Zero Value when you reassign it，but after you called Remove it's length change to -1(removed one element from an empty list).

[gopherbot]

Change https://golang.org/cl/233326 mentions this issue: container/list: check the list state before mutation

[cagedmantis]

/cc @griesemer

[cagedmantis]

I'm confirming that the code above reproduces. Resetting the list does not change the pointer to the list. The element still has the pointer to the original list. The Remove() function checks if the pointer to the list is the same as the pointer to list in the element.

[josharian]

Resetting the list does not change the pointer to the list.

Seems like that could also cause memory leaks.

[adonovan]

See #70022 (comment) for possible mitigations, including merely documenting it.