os: error reading Stdin on windows

[alexbrainman]

I tried to verify if recently closed issue #6303 is fixed, but the program mentioned in the issue is broken now:

C:\dev\src\a>go version
go version devel +97f854c Sat Dec 19 10:00:04 2015 +0000 windows/386

C:\dev\src\a>type foo.go
package main

import (
        "fmt"
        "io"
        "os"
)

func main() {
        n, err := io.Copy(os.Stdout, os.Stdin)
        fmt.Printf("n=%d err=%v\n", n, err)
}

C:\dev\src\a>go build foo.go && foo.exe
n=0 err=read /dev/stdin: Not enough storage is available to process this command.

C:\dev\src\a>

Alex

[mattn]

I can't reproduce it.

[alexbrainman]

It is syscall.ReadFile returns ERROR_NOT_ENOUGH_MEMORY. I can reproduce it on my both winxp and windows 7.

Alex

[mattn]

I'm also using windows7. Is it related issue of 32bit/64bit?

[alexbrainman]

Is it related issue of 32bit/64bit?

My windows xp is 32bit, and my windows 7 is 64bit.

Alex

[mattn]

This is not reproduced on Windows7 32bit.

[azdagron]

I also cannot reproduce on Windows 10 64-bit using the 1.6beta1 build:

Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\dev\src\a>go version
go version go1.6beta1 windows/amd64

C:\dev\src\a>type foo.go
package main

import (
        "fmt"
        "io"
        "os"
)

func main() {
        n, err := io.Copy(os.Stdout, os.Stdin)
        fmt.Printf("n=%d err=%v\n", n, err)
}

C:\dev\src\a>go build foo.go && foo.exe
This
This
is
is
a
a
test.
test.
^Z
n=20 err=<nil>

[alexbrainman]

More information. This fails only if my executable is windows-386 - it fails on both 32bit windows xp and 64bit my windows 7. It works as expected if executable is windows-amd64.

Alex

[rsc]

From https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx

The ReadFile function may fail with ERROR_INVALID_USER_BUFFER or ERROR_NOT_ENOUGH_MEMORY whenever there are too many outstanding asynchronous I/O requests.

I don't see how that's possible, of course, since this is the first read in the entire program.

Actually http://microsoft.public.win32.programmer.kernel.narkive.com/A5Q9kG7J/reading-console-input suggests the maximum size you can read from the console is "0x77E8".

Can you try this diff:

diff --git a/src/os/file_windows.go b/src/os/file_windows.go
index bda495e..f260a72 100644
--- a/src/os/file_windows.go
+++ b/src/os/file_windows.go
@@ -264,9 +264,9 @@ func (f *File) readConsole(b []byte) (n int, err error) {
    }
    if len(f.readbuf) == 0 {
        numBytes := len(b)
-       // Windows  can't read bytes over max of int16.
-       if numBytes > 32767 {
-           numBytes = 32767
+       // Windows can't read bytes over max of int16.
+       if numBytes > 30000 {
+           numBytes = 30000
        }
        mbytes := make([]byte, numBytes)
        var nmb uint32

[alexbrainman]

Can you try this diff:

That does not help. You should be able to reproduce this yourself even on windows-amd64 - you just need to build windows-386 exe.

Alex

[rsc]

Unfortunately I've forgotten the password to my windows-amd64 laptop, and the gomote builders do not have stdin attached to the console. But thanks for trying.

[mattn]

@alexbrainman I tried the patch with GOARCH=386. When numBytes is 32767, I reproduce it.

But

diff --git a/src/os/file_windows.go b/src/os/file_windows.go
index bda495e..ed02962 100644
--- a/src/os/file_windows.go
+++ b/src/os/file_windows.go
@@ -265,8 +265,8 @@ func (f *File) readConsole(b []byte) (n int, err error) {
    if len(f.readbuf) == 0 {
        numBytes := len(b)
        // Windows  can't read bytes over max of int16.
-       if numBytes > 32767 {
-           numBytes = 32767
+       if numBytes > 30000 {
+           numBytes = 30000
        }
        mbytes := make([]byte, numBytes)
        var nmb uint32

When numBytes = 30000, it fixes this.

[mattn]

I tried this on windows7 64bit. And go build with set GOARCH=386.

[alexbrainman]

@mattn it does not fixes it fro me on Windows XP windows-386.

Alex

[mattn]

@alexbrainman if the numBytes is more fewer, how it work?

[alexbrainman]

@alexbrainman if the numBytes is more fewer, how it work?

Which numBytes do you want me to try? If you give me a number, I will try.

Alex

[mattn]

@alexbrainman 28672 please.

http://www.statmt.org/moses/html/d5/dfc/file_8cc_source.html#l00156

[alexbrainman]

28672 please

Same result. Still broken.

Alex

[rsc]

I don't know what's going on, but it's certainly not wrong to read fewer bytes, and this does help on some systems, so I am going to send a CL lowering the max. It's not going to matter too much whether we read 32,000 or even 10,000 chars at a time from the console.

[alexbrainman]

Now my program above works on both 386 and amd64. I will let @rsc decide what to do next.

Alex

[rsc]

I'm a little confused but it sounds like no one has a program that fails anymore. Sounds fixed to me!