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

builtin: documentation about make #7832

Closed
rui314 opened this issue Apr 22, 2014 · 6 comments
Closed

builtin: documentation about make #7832

rui314 opened this issue Apr 22, 2014 · 6 comments

Comments

@rui314
Copy link
Member

@rui314 rui314 commented Apr 22, 2014

What does 'go version' print?
go version devel +877b2382424b Wed Apr 16 14:36:44 2014 -0700 + linux/amd64

What steps reproduce the problem?
If make fails to allocate memory (e.g. requested object is too large), it seems to
panic. I think that fact is not documented anywhere. We might want to document that, so
that users can handle memory allocation error in a reliable manner.
@minux
Copy link
Member

@minux minux commented Apr 22, 2014

Comment 1:

the problem is that the user can't recover from oom situations, so really the only
reliable way is try not allocating too much.

@rui314
Copy link
Member Author

@rui314 rui314 commented Apr 22, 2014

Comment 2:

I don't agree -- I'd think there's a situation that user can gracefully handle OOM. For
example, in bytes/buffer.go, it recovers from a panic from make to return an ErrTooLarge
to user.

@minux
Copy link
Member

@minux minux commented Apr 22, 2014

Comment 3:

that's entirely different thing.
you can recover from that case simply because there is a static check inside runtime for
unreasonable len/caps.
If the actual memory allocation fails,
the program will crash.
And I think that's implementation detail
that shouldn't be exposed, as they are
not reliable and only catches silly errors.
If we want to document it, just say if make
can't fulfill the request, it will panic,
and it might or might not be recoverable.

@rui314
Copy link
Member Author

@rui314 rui314 commented Apr 22, 2014

Comment 4:

I agree that in general OOM is not recoverable, but what's in my mind is the case when
user wants to do a similar thing as bytes.buffer does.

@minux
Copy link
Member

@minux minux commented Apr 22, 2014

Comment 5:

but as I said, that only catches very silly errors like allocating a slice that's
bigger than the maximum heap size, and in that case, the user can easily
check the argument himself.
this kind of test is implementation detail, and I doubt we want to expose
to the user. (Because it can change at any time, and other Go implementations
might just blindly allocate the memory and crash, so the user can't even
rely on this behavior if he wants to write portable Go.)

@robpike
Copy link
Contributor

@robpike robpike commented Apr 27, 2014

Comment 6:

See also issue #7871.
By the way, it does not panic, it exits the program.

Status changed to WontFix.

@rui314 rui314 added the wontfix label Apr 27, 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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants