runtime: failed to commit pages (windows)

[alexbrainman]

This issue is similar to 7143.

U:\>type main.go
package main

import (
        "runtime/debug"
)

func main() {
        n := 550000
        buffs := make(chan []byte, n)
        for i := 0; i < n; i++ {
                buffs <- make([]byte, 1500)
        }
        for i := 0; i < n; i++ {
                <-buffs
        }
        debug.FreeOSMemory()
        for i := 0; i < n; i++ {
                buffs <- make([]byte, 1500)
        }
        for i := 0; i < n; i++ {
                <-buffs
        }
}

U:\>go build main.go

U:\>main.exe
fatal error: runtime: failed to commit pages

goroutine 16 [running]:
runtime.throw(0x5228c2)
        C:/go/root/src/pkg/runtime/panic.c:520 +0x71 fp=0x30c63e14
runtime.SysUsed(0x41526000, 0xd5c000)
        C:/go/root/src/pkg/runtime/mem_windows.c:72 +0x70 fp=0x30c63e34
MHeap_AllocLocked(0x531780, 0x1, 0x23)
        C:/go/root/src/pkg/runtime/mheap.c:240 +0x147 fp=0x30c63e54
runtime.MHeap_Alloc(0x531780, 0x1, 0x23, 0x30c60100)
        C:/go/root/src/pkg/runtime/mheap.c:178 +0x8b fp=0x30c63e68
MCentral_Grow(0x537e60)
        C:/go/root/src/pkg/runtime/mcentral.c:265 +0x83 fp=0x30c63e9c
runtime.MCentral_CacheSpan(0x537e60)
        C:/go/root/src/pkg/runtime/mcentral.c:84 +0x10d fp=0x30c63ebc
runtime.MCache_Refill(0x30b70000, 0x23)
        C:/go/root/src/pkg/runtime/mcache.c:78 +0xf7 fp=0x30c63ed4
runtime.mallocgc(0x600, 0x48c561, 0x1)
        C:/go/root/src/pkg/runtime/malloc.goc:151 +0x2df fp=0x30c63f08
cnew(0x48c560, 0x5dc, 0x1)
        C:/go/root/src/pkg/runtime/malloc.goc:835 +0xad fp=0x30c63f18
runtime.cnewarray(0x48c560, 0x5dc)
        C:/go/root/src/pkg/runtime/malloc.goc:848 +0x3f fp=0x30c63f28
makeslice1(0x489120, 0x5dc, 0x5dc, 0x30c63f68)
        C:/go/root/src/pkg/runtime/slice.goc:55 +0x4b fp=0x30c63f34
runtime.makeslice(0x489120, 0x5dc, 0x0, 0x5dc, 0x0, 0x0, 0x5dc, 0x5dc)
        C:/go/root/src/pkg/runtime/slice.goc:36 +0xb2 fp=0x30c63f54
main.main()
        U:/main.go:18 +0x13e fp=0x30c63f9c
runtime.main()
        C:/go/root/src/pkg/runtime/proc.c:247 +0x11e fp=0x30c63fd0
runtime.goexit()
        C:/go/root/src/pkg/runtime/proc.c:1445 fp=0x30c63fd4
created by _rt0_go
        C:/go/root/src/pkg/runtime/asm_386.s:101 +0x102

goroutine 19 [finalizer wait]:
runtime.park(0x4123d0, 0x526480, 0x525809)
        C:/go/root/src/pkg/runtime/proc.c:1369 +0x94
runtime.parkunlock(0x526480, 0x525809)
        C:/go/root/src/pkg/runtime/proc.c:1385 +0x3f
runfinq()
        C:/go/root/src/pkg/runtime/mgc0.c:2640 +0xc5
runtime.goexit()
        C:/go/root/src/pkg/runtime/proc.c:1445

U:\>go version
go version devel +4a839bf01b58 Tue May 20 15:52:08 2014 +1000 windows/386

I wonder if we can apply similar solution to 3ac2308bca2a. The solution assumes that
calls to SysUnused are rare. I'm not sure this is the same. On the other hand, perhaps
slow program is better then crashing program. Looking for advice.

Alex

[gopherbot]

Comment 1 by salvor.public:

This problem only happens (for me) when BOTH of these conditions are met:
1. main.exe runs from a network drive
2. OS is Windows XP 32-bit
On Windows XP, the example program doesn't crash when I copied main.exe to C:\temp\ and
ran it from there.
On Windows 8 64-bit and Windows 7 64-bit, the same main.exe (32-bit) doesn't crash from
my network drive (coincidentally named U:) I ran it more than 20 times successfully from
network U: drive.
Here are the 32-bit versions of go I tested (built with latest 32-bit TDM-GCC.)
go version devel +abe528ee4a57 Mon May 19 10:12:15 2014 -0700 windows/386       
go version devel +4a839bf01b58 Tue May 20 15:52:08 2014 +1000 windows/386
Windows versions tested:
Windows 8 64-bit (native)
Windows 7 64-bit (VMware Workstation)
Windows XP 32-bit (VMware Workstation)
Unfortunately, I don't have 32-bit Windows 7 handy for testing. It would be nice to know
how that flavor handles this program from a network drive.

[alexbrainman]

Comment 2:

Yes, the test is not reliable. Sometimes it crashes, sometimes it is not. Tested on
windows/386 only.
Alex

[rsc]

Comment 3:

My guess is that you can copy the loop from SysUnused into SysUsed (adjusting the call
arguments).

Labels changed: added release-go1.3maybe.

Status changed to Accepted.

[rsc]

Comment 4:

If you want this fixed in the release we need a CL in the next day or two.

[rsc]

Comment 6:

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

[alexbrainman]

Comment 7:

I was away from home. Back now, but I am not sure I will have time to do it now. I would
like a reliable test here, but I don't have one. Let's leave it for 1.4.

[gopherbot]

Comment 8:

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

[rsc]

Comment 9:

This issue was closed by revision 048692e.

Status changed to Fixed.