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

Jump to bottom

x/exp/slices: mention possible memory leak in Compact doc #54728

Closed
Deleplace opened this issue Aug 29, 2022 · 6 comments
Closed

x/exp/slices: mention possible memory leak in Compact doc #54728

Deleplace opened this issue Aug 29, 2022 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unreleased

Comments

@Deleplace
Copy link
Contributor

Deleplace commented Aug 29, 2022 •
edited

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

$ go version
go version go1.19 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

I read the documentation comment of Compact

What did you expect to see?

A warning about the "right tail" values in the original slice, which are obsolete but may still contain pointers to large objects. The same problem applied to Delete (issue #54650, CL 425895 ) and was mitigated by updating the func doc.

What did you see instead?

"Compact modifies the contents of the slice s; it does not create a new slice."

Compact does not zero the "discarded" elements beyond the length of the returned slice, as can be read in the current implementation, which may have adverse memory consequences, as show by this sample code.

I will make a CL with an extra sentence in the func doc.
@gopherbot gopherbot added this to the Unreleased milestone Aug 29, 2022
@Deleplace
Copy link
Contributor Author

The same concern applies to CompactFunc, however CompactFunc's doc needs not be updated, because it already states "CompactFunc is like Compact".

@gopherbot
Copy link

Change https://go.dev/cl/426374 mentions this issue: slices: mention possible memory leak in Compact doc

@heschi heschi added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 29, 2022
@heschi
Copy link
Contributor

heschi commented Aug 29, 2022

cc @ianlancetaylor

@beoran
Copy link

beoran commented Sep 8, 2022

@Deleplace I would think that in stead of documenting the memory leak, it should be fixed. Otherwise people will have to implement their own safer Compact.

@randall77
Copy link
Contributor

@beoran I see it the same as slicing. If you have

s = [A B C D E]
s = s[:3]

Then there remain "invisible" references to D and E. The slicing operation does not zero the elements you sliced off for you.

@beoran
Copy link

beoran commented Sep 8, 2022

@randall77 Actually, I never thought about this, I will have to be more careful with slicing like this from now. Still, as long as I have the original array, I can zero the unnecessary elements. It would be useful if there was a generic operation that did this, and Compact seems like the ideal candidate.

@golang golang locked and limited conversation to collaborators Dec 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@beoran @randall77 @gopherbot @Deleplace @heschi