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

runtime: fatal: cannot map pages in arena address space #19514

Closed
mappu opened this issue Mar 12, 2017 · 4 comments
Closed

runtime: fatal: cannot map pages in arena address space #19514

mappu opened this issue Mar 12, 2017 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone
Go1.10

Comments

@mappu
Copy link

mappu commented Mar 12, 2017

What version of Go are you using (go version)?

go version go1.7.5 windows/amd64

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\DEV\_Gopath\
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1

What did you do?

Ran a bad program with a stack overflow.

What did you expect to see?

"error: Stack overflow" or "error: out of memory"

What did you see instead?

Process memory usage grows to about 4GB (this machine has 8GB physical) and then panics:

runtime: VirtualAlloc of 1048576 bytes failed with errno=1455
fatal error: runtime: cannot map pages in arena address space

runtime stack:
runtime.throw(0x50fb52, 0x30)
        c:/go/src/runtime/panic.go:566 +0x9c
runtime.sysMap(0xc136200000, 0x100000, 0x1, 0x5a8c98)
        c:/go/src/runtime/mem_windows.go:116 +0x12c
runtime.(*mheap).sysAlloc(0x58ff40, 0x100000, 0x58ff88)
        c:/go/src/runtime/malloc.go:407 +0x381
runtime.(*mheap).grow(0x58ff40, 0x29, 0x0)
        c:/go/src/runtime/mheap.go:726 +0x69
runtime.(*mheap).allocSpanLocked(0x58ff40, 0x29, 0xc04201c820)
        c:/go/src/runtime/mheap.go:630 +0x4f9
runtime.(*mheap).alloc_m(0x58ff40, 0x29, 0x100000000, 0x2a36c10)
        c:/go/src/runtime/mheap.go:515 +0xee
runtime.(*mheap).alloc.func1()
        c:/go/src/runtime/mheap.go:579 +0x52
runtime.systemstack(0x79fe68)
        c:/go/src/runtime/asm_amd64.s:314 +0xb5
runtime.(*mheap).alloc(0x58ff40, 0x29, 0x100000000, 0x2a36c10)
        c:/go/src/runtime/mheap.go:580 +0xa7
runtime.largeAlloc(0x515c8, 0x451c00, 0x2a36c10)
        c:/go/src/runtime/malloc.go:774 +0x9a
runtime.mallocgc.func1()
        c:/go/src/runtime/malloc.go:669 +0x45
runtime.systemstack(0xc042014000)
        c:/go/src/runtime/asm_amd64.s:298 +0x7e
runtime.mstart()
        c:/go/src/runtime/proc.go:1079

goroutine 1 [running]:
runtime.systemstack_switch()
        c:/go/src/runtime/asm_amd64.s:252 fp=0xc107e535e8 sp=0xc107e535e0
runtime.mallocgc(0x515c8, 0x0, 0x0, 0xc0414b7b23)
        c:/go/src/runtime/malloc.go:670 +0x94b fp=0xc107e53688 sp=0xc107e535e8
runtime.rawstring(0x515c8, 0x0, 0x0, 0x0, 0x0, 0x0)
        c:/go/src/runtime/string.go:289 +0x8c fp=0xc107e536c0 sp=0xc107e53688
runtime.rawstringtmp(0x0, 0x515c8, 0xc042010c00, 0xc107e53748, 0xc11790e000, 0x586f90, 0x500f40)
        c:/go/src/runtime/string.go:111 +0xa8 fp=0xc107e53700 sp=0xc107e536c0
runtime.slicebytetostring(0x0, 0xc11790e000, 0x515c8, 0x60000, 0x2, 0x2)
        c:/go/src/runtime/string.go:93 +0x45 fp=0xc107e53758 sp=0xc107e53700
fmt.Sprintf(0x50a41f, 0x11, 0xc107e538d0, 0x2, 0x2, 0x467ec0, 0xc04249e100)
        c:/go/src/fmt/print.go:197 +0x9d fp=0xc107e537b0 sp=0xc107e53758
my_application_code(0xc04225f720, 0xc1361a6000, 0x515ba, 0x2, 0xc042268480, 0x50e143, 0x21, 0xc107e539c0, 0x445312, 0x5782a8, ...)
        C:/my_application...

[same frame several hundred times]

...additional frames elided...

[no other goroutines running]

I acknowledge the underlying stack overflow is entirely my own fault. But, this kind of error message from the runtime is worrying. It reads as if the runtime attempted to do something invalid or dangerous, instead of intelligently handling the low-memory condition.

Is the runtime behaving correctly here? Is this the expected error message under memory pressure conditions?
@randall77
Copy link
Contributor

Yes, this is an expected error. What the runtime is telling you is that it tried to get some memory from the OS and the OS refused.
It could probably use a better error message, though.

@mappu
Copy link
Author

mappu commented Mar 12, 2017

OK.

I had originally understood the error to mean "prevented the runtime from allocating memory in space that the arena is already using". But if it's actually talking about committing reserved pages from the OS then it does make sense.

About improving the message:

Can the runtime resolve the errno=1455 into the appropriate Win32 error? It's ERROR_COMMITMENT_LIMIT "The paging file is too small for this operation to complete.", which, it's a little bit more clear.

Or "fatal: out of memory (some more detailed reason)" as is done in e.g. https://github.com/golang/go/blob/master/src/runtime/mcache.go#L124 .

@alexbrainman
Copy link
Member

Can the runtime resolve the errno=1455 into the appropriate Win32 error? It's ERROR_COMMITMENT_LIMIT "The paging file is too small for this operation to complete.", which, it's a little bit more clear.

You need to call FormatMessage Windows API to translate 1455 into "The paging file is too small for this operation to complete.". It might not be safe to do that if you find yourself in the "no free memory" situation. Do you think it is worth the risk getting your program into even more trouble? You might endup getting no error message printed at all. Would that be OK with you?

Alex

@bradfitz bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 21, 2017
@bradfitz bradfitz added this to the Go1.9Maybe milestone Mar 21, 2017
@gopherbot
Copy link

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

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.10 Jul 20, 2017
@golang golang locked and limited conversation to collaborators Jul 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Milestone
Go1.10
Development

No branches or pull requests
5 participants
@bradfitz @mappu @randall77 @gopherbot @alexbrainman