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

runtime: VirtualAlloc of 4294967296 bytes failed with errno=1455 on windows/amd64 go 1.13.4 #37029

glycerine opened this issue Feb 4, 2020 · 3 comments
FrozenDueToAge WaitingForInfo


Copy link

@glycerine glycerine commented Feb 4, 2020

I just encountered a similar panic to #33716 . I am running Go 1.13.4 windows/amd64. My windows VM has 5GB of RAM. Go tried to allocate 4GB of RAM and crashed. This is a big long running program (had been running for about 24 hours at the point of crash) so no easy repro test case available immediately.

It seems rather unreasonable for Go to ask for that much memory on a 5GB box.

runtime: VirtualAlloc of 4294967296 bytes failed with errno=1455
fatal error: out of memory

runtime stack:
runtime.throw(0x2977e71, 0xd)
c:/go/src/runtime/panic.go:774 +0x79
runtime.sysUsed(0xc280b26000, 0x100000000)
c:/go/src/runtime/mem_windows.go:83 +0x230
runtime.(*mheap).allocSpanLocked(0x4087660, 0x80000, 0x40ab448, 0x1210fda0)
c:/go/src/runtime/mheap.go:1228 +0x203
runtime.(*mheap).alloc_m(0x4087660, 0x80000, 0x101, 0x1210fdd0)
c:/go/src/runtime/mheap.go:1022 +0xd0
c:/go/src/runtime/mheap.go:1093 +0x53
runtime.(*mheap).alloc(0x4087660, 0x80000, 0x10101, 0xc000048000)
c:/go/src/runtime/mheap.go:1092 +0x91
runtime.largeAlloc(0xfffffe00, 0xc000040101, 0xc000056000)
c:/go/src/runtime/malloc.go:1138 +0x9e
c:/go/src/runtime/malloc.go:1033 +0x4d
c:/go/src/runtime/asm_amd64.s:370 +0x6b

goroutine 1 [running]:
c:/go/src/runtime/asm_amd64.s:330 fp=0xc0003e9108 sp=0xc0003e9100 pc=0x464f10
runtime.mallocgc(0xfffffe00, 0x26064a0, 0x1, 0xc0003e91d0)
c:/go/src/runtime/malloc.go:1032 +0x8d4 fp=0xc0003e91a8 sp=0xc0003e9108 pc=0x411344
runtime.makeslice(0x26064a0, 0xfffffe00, 0xfffffe00, 0x0)
c:/go/src/runtime/slice.go:49 +0x73 fp=0xc0003e91d8 sp=0xc0003e91a8 pc=0x44c4b3
bytes.makeSlice(0xfffffe00, 0x0, 0x0, 0x0)
c:/go/src/bytes/buffer.go:229 +0x7e fp=0xc0003e9240 sp=0xc0003e91d8 pc=0x535c2e
bytes.(*Buffer).grow(0xc0003e9368, 0x200, 0x40000000)
c:/go/src/bytes/buffer.go:142 +0x162 fp=0xc0003e9290 sp=0xc0003e9240 pc=0x535562
bytes.(*Buffer).ReadFrom(0xc0003e9368, 0x2e01ce0, 0xc0000060e0, 0x2917ea0, 0xc00006e120, 0xc0001
c:/go/src/bytes/buffer.go:202 +0x52 fp=0xc0003e9300 sp=0xc0003e9290 pc=0x535a12
io/ioutil.readAll(0x2e01ce0, 0xc0000060e0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
c:/go/src/io/ioutil/ioutil.go:36 +0x107 fp=0xc0003e93a0 sp=0xc0003e9300 pc=0x54c927

Copy link

@mknyszek mknyszek commented Feb 4, 2020

I replied on the other issue, but copying here for visibility:

@glycerine AFAICT your application ran out of memory. It looks like your application tried to read more than 4 GiB from an io.Reader and the OS determined it didn't have enough memory left to satisfy the allocation (note that the bytes.Buffer grows, calling makeSlice with an argument of 4294966784 bytes, which was then rounded up to 4 GiB even because it's allocating at a page granularity).

@toothrot toothrot added the NeedsInvestigation label Feb 6, 2020
@toothrot toothrot added this to the Backlog milestone Feb 6, 2020
@mknyszek mknyszek added WaitingForInfo and removed NeedsInvestigation labels Feb 24, 2020
Copy link

@mknyszek mknyszek commented Feb 24, 2020

To be clear, the runtime is asking the OS for 4 GiB of memory on behalf of your application. The request is ultimately coming from there. Please let me know if there are any further issues, though.

Copy link

@glycerine glycerine commented Mar 6, 2020

I tried running the GC manually more often, and that seems to have fixed it. So closing.

@golang golang locked and limited conversation to collaborators Mar 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
FrozenDueToAge WaitingForInfo
None yet

No branches or pull requests

4 participants