Can a Single String Constant Crash the Go Compiler with OOM?

Reproducing the Issue

The problem appears when running go build on a source file that defines a chain of string constants where each constant doubles the previous one. The code snippet below demonstrates the pattern (truncated at Z for brevity):

package p

const (
  a = "x"
  b = a + a
  c = b + b
  d = c + c
  e = d + d
  f = e + e
  g = f + f
  h = g + g
  i = h + h
  j = i + i
  k = j + j
  l = k + k
  m = l + l
  n = m + m
  o = n + n
  p = o + o
  q = p + p
  r = q + q
  s = r + r
  t = s + s
  u = t + t
  v = u + u
  w = v + v
  x = w + w
  y = x + x
  z = y + y
)

var _ = []rune(z[:])

Each line doubles the previous string, so by the time the constant reaches z its size is 2^25 bytes (≈32 MiB). Extending the chain to the uppercase Z would reach 2^51 bytes, roughly 2 PiB, which far exceeds typical machine memory.

Why Constants Differ from Variables

In Go, constants are evaluated at compile time and are not immediately bound to a concrete machine type. For example:

const n = 1 << 100

func main() {
    var _ int64 = n // compilation error: constant 1<<100 overflows int64
}

Similarly, a string constant is concatenated at compile time. The following simple constant works because the compiler can keep the exact value without materialising the full string:

const s = "hello, " + "go"

However, when the constant grows exponentially, the compiler must construct the full string to evaluate it, leading to massive memory allocation and eventual OOM.

Historical Context

Large constant handling has caused crashes before. Related Go issues include:

#18078 – slow compilation of huge string concatenations

#16394 – expectation that overly large strings should error instead of crashing the compiler

#9145 – older compiler crashes caused by massive string literals

#15729 – unnecessary copying of large string constants

Core Team's Response

The current issue (#78346) is still open and targeted for the Go 1.27 milestone. Alan Donovan suggested reporting an error when a constant string exceeds a certain length and replacing its value with unknown, similar to the existing handling for oversized integer constants. A change (CL 761300) introduced this check, but it was later disabled (CL 772220) because the implementation proved unstable. Subsequent work (CL 772320) added a StringLen helper to obtain the length without fully materialising the string, allowing early rejection of excessively large constants.

Practical Example

To illustrate a safe approach, the article provides a tiny program that tracks only the length of a concatenated constant string instead of building the string itself:

package main

import "fmt"

type ConstString struct { len uint64 }

func concat(a, b ConstString) ConstString { return ConstString{len: a.len + b.len} }

func main() {
    s := ConstString{len: 1}
    for i := 0; i < 52; i++ {
        s = concat(s, s)
        fmt.Println(i+1, s.len)
    }
}

This program prints the exponential growth of the length without allocating the actual string data.

Daily Precautions

For ordinary business code, such gigantic constants are unlikely. However, two scenarios deserve attention:

Code generation : Generators that embed large tables, test data, or resources directly as Go source constants can inadvertently create massive strings. Splitting data into chunks or using embed is recommended.

Online compilation services : Platforms that compile user‑submitted code must enforce strict resource limits (memory, CPU, timeout, process isolation) because malicious inputs can trigger the same OOM behaviour.

Conclusion

The issue remains unresolved pending Go 1.27. Developers who write code generators should audit generated files for overly large string, array, or map literals and avoid embedding them wholesale.