Navigation Menu

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

os: OpenBSD: TestFifoEOF hangs #25877

Closed
ianlancetaylor opened this issue Jun 13, 2018 · 9 comments
Closed

os: OpenBSD: TestFifoEOF hangs #25877

ianlancetaylor opened this issue Jun 13, 2018 · 9 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD
Milestone
Unplanned

Comments

@ianlancetaylor
Copy link
Contributor

On amd64 OpenBSD 6.2, the new os test TestFifoEOF simply hangs until the overall test times out. I don't know why. It seems to be true whether or not we poll on fifos, so it seems like a basic fifo problem.
I'm going to skip the test on OpenBSD.
@ianlancetaylor ianlancetaylor added OS-OpenBSD NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 13, 2018
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jun 13, 2018
@nmeum
Copy link

nmeum commented Oct 1, 2018 •
edited

I am currently writing a go program which makes heavy use of named pipes and works fine on Linux as is. Unfortunately, it hangs on OpenBSD 6.3 (amd64) with go 1.10 and I believe that this is due to this bug.

A minimal example to reproduce the hang I am experiencing is:

package main

import (
        "fmt"
        "os"
)

func main() {
        go func() {
                fmt.Println("writer: os.OpenFile")
                w, err := os.OpenFile("myfifo", os.O_WRONLY, 0)
                if err != nil {
                        panic(err)
                }
                fmt.Println("writer: os.OpenFile done")
                w.Close()
        }()

        fmt.Println("reader: os.OpenFile")
        r, err := os.OpenFile("myfifo", os.O_RDONLY, 0)
        if err != nil {
                panic(err)
        }
        fmt.Println("reader: os.OpenFile done")
        r.Close()
}

Run as:

$ mkfifo myfifo
$ go run test.go
reader: os.OpenFile
writer: os.OpenFile

So both threads hang while attempting to open the named pipe. ktrace(1) reveals that both never return from the open syscall which likely explains why it doesn't matter "whether or not we poll on fifos":

 <…>
 45296 fifotest GIO   fd 1 wrote 20 bytes
       "reader: os.OpenFile
       "
 45296 fifotest RET   write 20/0x14
 45296 fifotest CALL  open(0xc420014120,0x10000<O_RDONLY|O_CLOEXEC>)
 45296 fifotest NAMI  "myfifo"
 45296 fifotest RET   nanosleep 0
 45296 fifotest CALL  clock_gettime(CLOCK_MONOTONIC,0xc420041f08)
 45296 fifotest STRU  struct timespec { 1761091.403056708 }
 45296 fifotest RET   clock_gettime 0
 45296 fifotest CALL  nanosleep(0xc420041f08,0)
 45296 fifotest STRU  struct timespec { 0.000020000 }
 45296 fifotest RET   nanosleep 0
 45296 fifotest CALL  clock_gettime(CLOCK_MONOTONIC,0xc420041f08)
 45296 fifotest STRU  struct timespec { 1761091.423613458 }
 45296 fifotest RET   clock_gettime 0
 45296 fifotest CALL  __thrwakeup(0xc4200327b8,1)
 45296 fifotest RET   __thrwakeup 0
 45296 fifotest CALL  nanosleep(0xc420041f08,0)
 45296 fifotest STRU  struct timespec { 0.000020000 }
 45296 fifotest RET   __thrsleep 0
 45296 fifotest CALL  write(1,0xc420012160,0x14)
 45296 fifotest GIO   fd 1 wrote 20 bytes
       "writer: os.OpenFile
       "
 45296 fifotest RET   write 20/0x14
 45296 fifotest CALL  open(0xc420014127,0x10001<O_WRONLY|O_CLOEXEC>)
 45296 fifotest RET   nanosleep 0
 45296 fifotest CALL  clock_gettime(CLOCK_MONOTONIC,0xc420041f08)
 45296 fifotest STRU  struct timespec { 1761091.444142068 }
 45296 fifotest RET   clock_gettime 0
 45296 fifotest CALL  nanosleep(0xc420041f08,0)
 45296 fifotest STRU  struct timespec { 0.000020000 }
 45296 fifotest RET   nanosleep 0
 45296 fifotest CALL  clock_gettime(CLOCK_MONOTONIC,0xc420041f08)
 45296 fifotest STRU  struct timespec { 1761091.464243148 }
 45296 fifotest RET   clock_gettime 0
 45296 fifotest CALL  sigprocmask(SIG_SETMASK,~0<>)
 45296 fifotest RET   sigprocmask 0<>
 45296 fifotest CALL  __tfork(0xc420041de8,24)
 45296 fifotest STRU  struct __tfork { tcb=0xc420032888, tid=0xc420032848, stack=0xc420040000 }
 45296 fifotest RET   __tfork 445493/0x6cc35
 45296 fifotest CALL  sigprocmask(SIG_SETMASK,0<>)
 45296 fifotest RET   sigprocmask ~0x10100<SIGKILL|SIGSTOP>
 45296 fifotest CALL  nanosleep(0xc420041f08,0)
 45296 fifotest STRU  struct timespec { 0.000020000 }
 45296 fifotest RET   __tfork 0
 45296 fifotest CALL  __set_tcb(0xc420032890)
 45296 fifotest RET   __set_tcb 0
 45296 fifotest CALL  sigaltstack(0,0xc42003ff60)
 45296 fifotest RET   sigaltstack 0
 45296 fifotest CALL  sigaltstack(0xc42003ff28,0)
 45296 fifotest RET   sigaltstack 0
 45296 fifotest CALL  sigprocmask(SIG_SETMASK,0<>)
 45296 fifotest RET   sigprocmask ~0x10100<SIGKILL|SIGSTOP>
 45296 fifotest CALL  __thrsleep(0xc420032bb8,CLOCK_MONOTONIC,0,0,0xc420032bb8)
 45296 fifotest RET   nanosleep 0
  <…>

I don't know much about go internals but might this be a userspace scheduling problem?

Complete ktrace output: https://github.com/golang/go/files/2435881/ktrace.txt

@nmeum
Copy link

nmeum commented Nov 18, 2018 •
edited

I can no longer reproduce this issue on OpenBSD 6.4 with go1.11. The TestFifoEOF test passes fine on OpenBSD 6.4. @ianlancetaylor could you confirm that this is the case, close this issue and reenable the test on OpenBSD?

@refacto
Copy link

refacto commented Jan 29, 2019 •
edited

@ianlancetaylor Ping? Has been a good couple of months.

@ianlancetaylor
Copy link
Contributor Author

We still claim to support OpenBSD 6.2 (https://golang.org/wiki/OpenBSD). Until we require OpenBSD 6.4, it seems to me that we should keep the test disabled. (I have no opinion at all as to which versions of OpenBSD we should support.)

@ianlancetaylor ianlancetaylor added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 29, 2019
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 29, 2019
@bcmills bcmills mentioned this issue Oct 31, 2019
Closed
@nmeum
Copy link

nmeum commented Jun 11, 2020 •
edited

OpenBSD 6.2 has been EOL for quite some time now. Can this test be re-enabled on OpenBSD now?

@ianlancetaylor
Copy link
Contributor Author

I'm not really sure who our OpenBSD maintainers are. CC @mdempsky @4a6f656c in case they know.

@mdempsky
Copy link
Member

OpenBSD upstream only supports the last two major releases, which at the moment is 6.7 and 6.6.

If TestFifoEOF is passing on 6.4 and newer, I think it makes sense to just re-enable it and close this issue.

@nmeum
Copy link

nmeum commented Jun 20, 2020 •
edited

If we all agree that this is a good idea, could someone remove the corresponding lines from src/os/fifo_test.go? I would submit such a patch myself but I don't have a google account and can therefore not sign the CLA.

@bcmills bcmills mentioned this issue Feb 19, 2021
Closed
@gopherbot
Copy link

Change https://golang.org/cl/329732 mentions this issue: os: enable TestFifoEOF on openbsd

@golang golang locked and limited conversation to collaborators Jun 24, 2022
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. OS-OpenBSD
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@mdempsky @nmeum @ianlancetaylor @gopherbot @refacto