Ilink64 error fatal out of memory

Go Up to Using ILINK32 and ILINK64 on the Command Line

When using the RAD Studio ILINK32 or ILINK64, you may receive the Fatal: Out of memory message. To handle it, you need to identify the Linker heap that is out of memory and increase its size.

To increase the memory size in the needed heap, do the following:

1. Go to Tools > Options > IDE > Compiling and Running.
2. To see which Linker heap caused the problem, select Diagnostic on the Verbosity menu.
3. Try to link again, and when you see the Fatal: Out of memory message, click the Output tab. It contains additional information that identifies which Linker heap was overrun.
4. On the Output tab, find the following line:

Overrun on linker heap:

The heap that you see after the Overrun on linker heap: message is the heap that was overrun.

Values for all heaps are listed below this line. Please see the example below.

• Look at the two hex values following the heap that is overrun.

• The first value shows the size required by the linker when it realized that the heap would be overrun.
• The second value shows the allocated size.

• Compare the first and second values and pick a value for the heap that exceeds the first value.

5. Now, you can increase the size of the needed heap. To do it, go to Project > Options > C++ Linker and in the Linker Heap Settings section, set the new heap size.

• For the 32-bit Windows platform, there are 5 heaps. In most cases, it’s enough to increase 3 of them: Code Heap Size, Data Heap Size, or Info Heap Size. Please see the sample values used in a reported test case:

• Code Heap Size: 0x14000000
• Data Heap Size: 0x0d000000
• Info Heap Size: 0x0B000000
• RO Data Heap Size: 0
• TDS Heap Size: 0

• For the 64-bit Windows platform, there are 14 heaps. In most cases, it’s enough to increase 2 of them: Dwarf pubtypes Heap Size, or Dwarf aranges Heap Size. Please see the sample values used in a reported test case:

• Code Heap Size: 0
• Data Heap Size: 0
• Dwarf abrbrev Heap Size: 0
• Dwarf aranges Heap Size: 0
• Dwarf info Heap Size: 0
• Dwarf line Heap Size: 0
• Dwarf loc Heap Size: 0
• Dwarf macinfo Heap Size: 0
• Dwarf pubtypes Heap Size: 0x02400000
• Dwarf ranges Heap Size: 0
• Dwarf str Heap Size: 0x08000000
• Info Heap Size: 0
• RO Data Heap Size: 0
• TDS Heap Size: 0

6. Try to link again. In case you see the Fatal: Out of memory message again, repeat the procedure because you might need to increase the memory for other heaps too.

Note: Each application requires increasing different heaps and different values.

Command-Line Flags

In a command-line build, the linker will emit a table like the following example:

Turbo Incremental Link64 6.80 Copyright (c) 1997-2017 Embarcadero Technologies,
Inc.
Overrun on linker heap: info
Linker Heaps
------------
info                   0x12271000  0x12000000
code                   0x0487d000  0x08000000
rodata                 0x00159000  0x06000000
data                   0x029bb000  0x08000000
bss                    0x08000000  0x08000000
dwarf_aranges          0x00010000  0x00200000
dwarf_macinfo          0x00010000  0x00200000
dwarf_pubtypes         0x00275000  0x02000000
dwarf_info             0x04e57000  0x06000000
dwarf_abbrev           0x00040000  0x00200000
dwarf_line             0x0124d000  0x02000000
dwarf_str              0x036e0000  0x06000000
dwarf_loc              0x00070000  0x02000000
dwarf_ranges           0x00275000  0x02000000
Fatal: Out of memory

You can change the heap sizes the linker uses via the -GH flag for ilink32 or ilink64. Use -GH<heapname>=size to allocate a larger heap or multiple heaps. For example, to link the release version of the DLL OWLNext library, internal C++Builder developers use -GHinfo=0x13000000.

See Also

• Using ILINK32 and ILINK64 on the Command Line
• Technical Details About ILINK32 and ILINK64
• C++ Linker

Explanation

On your computer, one of the linker heaps is too small for this project. The project links with Link with Dynamic RTL option, because in that case the linker needs less memory, and the heap just happens to be large enough.

You can use -GH linker option to increase that heap, but first you have to find out which heap overflows. To do that, enable diagnostic output in the linker.

Compiling with diagnostic output

Compiling from the command line:

call rsvars
MSBuild /v:diag YourProject.cbproj

Compiling from the IDE:

• Go to Tools > Options > Environment Options
• Change Verbosity to Diagnostic
• After building the project, read output from the Output tab of the Messages window

Increasing heap sizes

Near the end of the output, you should find sizes of heaps, similar to this:

The "ILINK32" task is using "ilink32" from "c:program files (x86)embarcaderostudio18.0binilink32.exe".
Turbo Incremental Link 6.75 Copyright (c) 1997-2016 Embarcadero Technologies, Inc.
Overrun on linker heap: tds
Linker Heaps
------------
system                 0x030d4000  0x08000000
tds                    0x08710000  0x09400000
c:program files (x86)embarcaderostudio18.0BinCodeGear.Cpp.Targets(3517,5): error : Fatal: Out of memory
The command exited with code 2.

In this case, overflow happened in heap tds, so we need to increase its size. The left column gives the number of bytes in use, and the right column gives the number of bytes allocated. The new size should be larger than the value that is currently in the right column.

In this case, tds size was 0x09400000, so we increase it to 0x0f400000 with the following option: -GHtds=0x0f400000.

In the IDE, go to Project > Options > C++ Linker. Add -GHtds=0x0f400000 to Advanced > Additional Options.

After saving project options, compile the project again. If the same heap overflows, you need to increase its size even more. If another heap overflows, you need to increase its size as well.

For example, if code heap overflows now, and you want to increase its size to 0x0a000000, you should change Additional Options to -GHtds=0x0f400000 -GHcode=0x0a000000.

If you increase the heap too much, you will get LME288 error instead. That means you have reached the maximum size for some heap. If even the maximum size is not enough for your project, it seems C++ Builder 10.2.3. has doubled the maximum size, so you could migrate to that version, or copy ilink32.exe from 10.2.3. installation to use with an older version of C++ Builder.

More details

• How to report a C++ Compiler or Linker problem and workarounds
• «Unable to perform link» error when compiling in RAD Studio XE8

Did this not fix the problem?

• If you are using C++ Builder 10.0 or 10.1, try to patch your linker as described here: LME288 Error in C++ Builder
• If you are using C++ Builder 10.2, patching the linker does not work, but you can try other solutions in the same link
• C++ Builder 10.2. has settings for managing heaps: Handling Out of Memory Errors

1 ответ

Please answer these questions before submitting your issue. Thanks!

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

go version go1.10.3 linux/amd64

Does this issue reproduce with the latest release?

yes

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

GOARCH=»amd64″
GOBIN=»»
GOCACHE=»/home/hs/.cache/go-build»
GOEXE=»»
GOHOSTARCH=»amd64″
GOHOSTOS=»linux»
GOOS=»linux»
GOPATH=»/home/hs/go»
GORACE=»»
GOROOT=»/usr/local/go»
GOTMPDIR=»»
GOTOOLDIR=»/usr/local/go/pkg/tool/linux_amd64″
GCCGO=»gccgo»
CC=»gcc»
CXX=»g++»
CGO_ENABLED=»1″
CGO_CFLAGS=»-g -O2″
CGO_CPPFLAGS=»»
CGO_CXXFLAGS=»-g -O2″
CGO_FFLAGS=»-g -O2″
CGO_LDFLAGS=»-g -O2″
PKG_CONFIG=»pkg-config»
GOGCCFLAGS=»-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build755635740=/tmp/go-build -gno-record-gcc-switches»

What did you do?

$ go get -d k8s.io/kubernetes
$ cd $GOPATH/src/k8s.io/kubernetes
$ make

What did you expect to see?

make to pass

What did you see instead?

:~/go/src/k8s.io/kubernetes$ make
+++ [0626 06:46:31] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/deepcopy-gen
+++ [0626 06:46:47] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/defaulter-gen
+++ [0626 06:46:55] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/conversion-gen
+++ [0626 06:47:04] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/openapi-gen
+++ [0626 06:47:16] Building go targets for linux/amd64:
./vendor/github.com/jteeuwen/go-bindata/go-bindata
+++ [0626 06:47:18] Building go targets for linux/amd64:
cmd/kube-proxy
cmd/kube-apiserver
cmd/kube-controller-manager
cmd/cloud-controller-manager
cmd/kubelet
cmd/kubeadm
cmd/hyperkube
cmd/kube-scheduler
vendor/k8s.io/kube-aggregator
vendor/k8s.io/apiextensions-apiserver
cluster/gce/gci/mounter
cmd/kubectl
cmd/gendocs
cmd/genkubedocs
cmd/genman
cmd/genyaml
cmd/genswaggertypedocs
cmd/linkcheck
vendor/github.com/onsi/ginkgo/ginkgo
test/e2e/e2e.test
cmd/kubemark
vendor/github.com/onsi/ginkgo/ginkgo
test/e2e_node/e2e_node.test
/usr/local/go/pkg/tool/linux_amd64/link: signal: killed

k8s.io/kubernetes/cmd/genman
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x5fda68, 0x16)
/usr/local/go/src/runtime/panic.go:616 +0x81
runtime.sysMap(0xc4674d0000, 0x100000, 0x548f00, 0x7178d8)
/usr/local/go/src/runtime/mem_linux.go:216 +0x20a
runtime.(*mheap).sysAlloc(0x6fef40, 0x100000, 0x7f745d115c98)
/usr/local/go/src/runtime/malloc.go:470 +0xd4
runtime.(*mheap).grow(0x6fef40, 0x1f, 0x0)
/usr/local/go/src/runtime/mheap.go:907 +0x60
runtime.(*mheap).allocSpanLocked(0x6fef40, 0x1f, 0x7178e8, 0x7ffd7fcc8a40)
/usr/local/go/src/runtime/mheap.go:820 +0x301
runtime.(*mheap).alloc_m(0x6fef40, 0x1f, 0x410100, 0xc41dc5a3ff)
/usr/local/go/src/runtime/mheap.go:686 +0x118
runtime.(*mheap).alloc.func1()
/usr/local/go/src/runtime/mheap.go:753 +0x4d
runtime.(*mheap).alloc(0x6fef40, 0x1f, 0x7ffd7f010100, 0x412e8c)
/usr/local/go/src/runtime/mheap.go:752 +0x8a
runtime.largeAlloc(0x3c8c0, 0x440001, 0x7f745da5a6c8)
/usr/local/go/src/runtime/malloc.go:826 +0x94
runtime.mallocgc.func1()
/usr/local/go/src/runtime/malloc.go:721 +0x46
runtime.systemstack(0x0)
/usr/local/go/src/runtime/asm_amd64.s:409 +0x79
runtime.mstart()
/usr/local/go/src/runtime/proc.go:1175

goroutine 1 [running]:
runtime.systemstack_switch()
/usr/local/go/src/runtime/asm_amd64.s:363 fp=0xc42062e390 sp=0xc42062e388 pc=0x451b50
runtime.mallocgc(0x3c8c0, 0x5f2780, 0x301, 0xc4552f01a0)
/usr/local/go/src/runtime/malloc.go:720 +0x8a2 fp=0xc42062e430 sp=0xc42062e390 pc=0x40f5c2
runtime.makeslice(0x5f2780, 0x3e8, 0x3e8, 0xc5, 0x7174a0, 0xc466a34c00)
/usr/local/go/src/runtime/slice.go:61 +0x77 fp=0xc42062e460 sp=0xc42062e430 pc=0x43e247
cmd/link/internal/sym.(*Symbols).Newsym(…)
/usr/local/go/src/cmd/link/internal/sym/symbols.go:56
cmd/link/internal/sym.(*Symbols).Lookup(0xc42050e000, 0xc4674b0ea0, 0xc5, 0x0, 0xc4674967c8)
/usr/local/go/src/cmd/link/internal/sym/symbols.go:79 +0x299 fp=0xc42062e4c8 sp=0xc42062e460 pc=0x4d71a9
cmd/link/internal/objfile.(*objReader).readRef(0xc42062e8a0)
/usr/local/go/src/cmd/link/internal/objfile/objfile.go:390 +0x10d fp=0xc42062e5f0 sp=0xc42062e4c8 pc=0x4f7b0d
cmd/link/internal/objfile.(*objReader).loadObjFile(0xc42062e8a0)
/usr/local/go/src/cmd/link/internal/objfile/objfile.go:109 +0x2ce fp=0xc42062e7e8 sp=0xc42062e5f0 pc=0x4f4f3e
cmd/link/internal/objfile.Load(0x6ed3a0, 0xc42050e000, 0xc436847c50, 0xc44341c240, 0x88bb8, 0xc447614150, 0x2b)
/usr/local/go/src/cmd/link/internal/objfile/objfile.go:69 +0x1a1 fp=0xc42062e9c8 sp=0xc42062e7e8 pc=0x4f4a61
cmd/link/internal/ld.ldobj(0xc420512000, 0xc436847c50, 0xc44341c240, 0x88c24, 0xc447614150, 0x2b, 0xc4205a8470, 0x23, 0x1, 0x0)
/usr/local/go/src/cmd/link/internal/ld/lib.go:1515 +0xcb1 fp=0xc42062ec80 sp=0xc42062e9c8 pc=0x54f611
cmd/link/internal/ld.loadobjfile(0xc420512000, 0xc44341c240)
/usr/local/go/src/cmd/link/internal/ld/lib.go:839 +0x50d fp=0xc42062ee68 sp=0xc42062ec80 pc=0x548fbd
cmd/link/internal/ld.(*Link).loadlib(0xc420512000)
/usr/local/go/src/cmd/link/internal/ld/lib.go:365 +0x183 fp=0xc42062f110 sp=0xc42062ee68 pc=0x545a33
cmd/link/internal/ld.Main(0x6ed3a0, 0x10, 0x20, 0x1, 0x7, 0x10, 0x5ff52e, 0x1b, 0x5fc864, 0x14, …)
/usr/local/go/src/cmd/link/internal/ld/main.go:201 +0xa73 fp=0xc42062f2a0 sp=0xc42062f110 pc=0x55d4d3
main.main()
/usr/local/go/src/cmd/link/main.go:62 +0x277 fp=0xc42062ff88 sp=0xc42062f2a0 pc=0x594ad7
runtime.main()
/usr/local/go/src/runtime/proc.go:198 +0x212 fp=0xc42062ffe0 sp=0xc42062ff88 pc=0x429f62
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc42062ffe8 sp=0xc42062ffe0 pc=0x454541
!!! [0626 06:57:13] Call tree:
!!! [0626 06:57:13] 1: /home/hs/go/src/k8s.io/kubernetes/hack/lib/golang.sh:610 kube::golang::build_binaries_for_platform(…)
!!! [0626 06:57:13] 2: hack/make-rules/build.sh:27 kube::golang::build_binaries(…)
!!! [0626 06:57:13] Call tree:
!!! [0626 06:57:13] 1: hack/make-rules/build.sh:27 kube::golang::build_binaries(…)
!!! [0626 06:57:13] Call tree:
!!! [0626 06:57:13] 1: hack/make-rules/build.sh:27 kube::golang::build_binaries(…)
Makefile:92: recipe for target ‘all’ failed
make: *** [all] Error 1