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

syscall: invalid computation of next available file descriptor in exec_plan9.go #5605

Closed
gopherbot opened this issue May 31, 2013 · 15 comments
Closed
Assignees
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented May 31, 2013

by lucio.dere:

What steps will reproduce the problem?

This is build time problem: the test sequence fails irregularly with a bad file
descriptor for the fork/exec operation.

What is the expected output?

Successful loading of one or more test programs.

What do you see instead?

An error report on failure to load because of an invalid file descriptor.

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

The Go build suite, in this case for the 386 architecture.

Which operating system are you using?

Plan 9.

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

"tip"

Details:

The current code in the module from around line 186 has been declared
flawed in that it seems to handle some conditions incorrectly.

I'd like to propose the following correction - based on the assumption
that the comment is correct:

        // Guard against side effects of shuffling fds below.
        // Make sure that nextfd is beyond any currently open files so
        // that we can't run the risk of overwriting any of them.
        nextfd = len(attr.Files)
        fd := make([]int, nextfd)
        for i, ufd := range attr.Files {
                if nextfd < int(ufd) {
                        nextfd = int(ufd) + 1
                }
                fd[i] = int(ufd)
        }
        fd = append(fd, nextfd)

I'm busy with a complicated code synchronisation problem right now, so
I can't test my proposal immediately.  Anybody is welcome to address
the problem in my stead.

Lucio.

PS: Actually, I think the above can be programmed more defensively,
without making any assumptions about the relationship between the
number of fds and their values.
@minux
Copy link
Member

@minux minux commented May 31, 2013

Comment 1:

Labels changed: added priority-later, os-plan9, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 2:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 3:

Labels changed: added feature.

@robpike
Copy link
Contributor

@robpike robpike commented Aug 29, 2013

Comment 4:

Not a blocker for 1.2.

Labels changed: removed go1.2maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 5:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 6:

Labels changed: removed feature.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 7:

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

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Dec 12, 2013

Comment 9 by jas@corpus-callosum.com:

I still see this during occasional builds with an error like:
go build math/rand: fork/exec /usr/jas/src/cmd/go/pkg/tool/plan9_386/pack: fd out of
range or not open
The result of such an error is that the final go target is not installed.
@ality
Copy link
Member

@ality ality commented Jan 31, 2014

Comment 10:

https://golang.org/cl/57890043/

Owner changed to @ality.

Status changed to Started.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Apr 9, 2014

Comment 11:

CL https://golang.org/cl/57890043 references this issue.
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Oct 2, 2014

Comment 12:

I've seen a number of these failures recently with "fd out of range or not open".
@0intro
Copy link
Member

@0intro 0intro commented Oct 2, 2014

Comment 14:

> go build syscall: pkg/tool/plan9_amd64/6g: fork/exec
> pkg/tool/plan9_amd64/6g: fd out of range or not open
I think these errors started to happen on the plan9/amd64
builder when Nick moved /tmp from cwfs to ramfs.
These errors doesn't happen on the plan9/386 builder,
were /tmp is served by Fossil.
I'm not sure how this is related to the issue reported
here, but the CL 57890043 deserves to be completed.
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@0intro 0intro self-assigned this Jul 30, 2015
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Apr 29, 2016

CL https://golang.org/cl/22610 mentions this issue.

@gopherbot gopherbot closed this in 639a20d May 5, 2016
@golang golang locked and limited conversation to collaborators May 5, 2017
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
7 participants
You can’t perform that action at this time.