Polygon.fromGeoJSON keeps a copy of the key path for every nesting level, so a valid 752 KB GeoJSON Feature runs out of a 512 MiB heap

SimpleGeoJSONPolygonParser, behind Polygon.fromGeoJSON, tracks its position with a path String (path + "." + key for an object member, path + ".[]" for an array element), and every recursive frame keeps its own copy alive until it returns, so live memory is about nesting depth times path length. A valid Feature whose properties hold one 750,000-char key over 900 nested empty arrays (751,925 chars, 902 levels) needs about 676 million chars of path strings at once and fails with OutOfMemoryError: Java heap space at Lucene's default 512 MiB test heap, with assertions on and off; it parses at 2 GiB, and the same nesting under a short key, or the same text as a string value, parses at 512 MiB. The path is only ever compared with five short constants and a crs prefix, so keeping its first 21 chars gives identical behaviour with linear memory. Present since the API was added in 6.2.0; ordinary, shallow GeoJSON with short keys is not at risk.

• parseObject(String path) (SimpleGeoJSONPolygonParser.java:100; comment at :99: "path is the \"address\" by keys of where we are, e.g. geometry.coordinates"). parse() starts with "" (:65).
• For a member whose value is an array or object it builds a new String, newPath = path + "." + key (:143, :151; just key at the top, :141, :149), and recurses with it (parseArray(newPath) at :145, parseObject(newPath) at :153).
• parseArray(String path) (:283) passes path + ".[]" to every nested array (:309) or object (:312).
• Each frame still needs its path while its child runs: parseArray uses it again for the next element (inside the loop), parseObject after the child returns (:174, :186, :205). So at depth d all d Strings are live at once.

path.equals("crs.properties") (:125, :174), path.startsWith("crs") (:186), path.equals("features.[]") || path.isEmpty() (:197), isValidGeometryPath (:192, :194, :205) = isEmpty() || equals("geometry") || equals("features.[].geometry") (:222-224), and path.length() == 0 (:140, :148). The longest constant is 20 chars. Error messages quote the input, not the path.

In the repro the first array's path is properties. + key = 750,011 chars, and each deeper level adds .[]. 900 such Strings total 900 x 750,011 + 3 x 899 x 900 / 2 = 676,223,550 chars; the JDK stores these Latin-1 Strings at one byte per char, so about 645 MiB, roughly 900 times the input. In general: about d x K + 1.5 d^2 bytes for d nested arrays under a K-char key, and about K x d^2 / 2 for d nested objects each under a K-char key. The hunt's model predicted the heap threshold of three shapes with the same d x K product (250 x 1 MiB, 500 x 512 KiB, 1,000 x 256 KiB) at 252-253 MiB; bisection on the stock jar measured 255 MiB for all three (serial collector). Exact thresholds depend on the JVM, the collector and the heap settings: with G1 at -Xmx512m on this JDK (1 MiB regions) each of these ~750 KB Strings is a humongous object that takes a whole region, which raises the need here by about a third (measured on the standalone runner, assertions off: the repro parses from -Xmx704m with the serial collector and from -Xmx928m with G1, and fails at 672m and 896m).

• Who. Applications that pass GeoJSON they do not control to Polygon.fromGeoJSON, for example to build a polygon filter from a request. Polygon is @lucene.experimental (Polygon.java:41) and advertises fromGeoJSON in its class javadoc (:25); outside tests (TestPolygon, TestTessellator) no Lucene code calls it.
• No setting involved. The parser has no options. The trigger scales with the heap: at 2 GiB the repro parses, and a proportionally longer key or deeper nesting fails there too (an independent reproducer's scaling run: depth 500 under a 200,000-char key fails at 96 MiB and parses at 112 MiB, while the same text as a string value parses at 32 MiB).
• Usual size and depth limits do not prevent it. The repro is 752 KB with 902 levels, below the 1,024-level default that #16423 chose for the expressions parser. A second witness, 1,000 nested property objects with 1,000-char keys (1,005,143 chars), also exhausts 512 MiB (standalone runner, G1). So a 1 MiB input limit plus a 1,000-level depth limit still lets a failing input through. Size and depth limits together do bound the memory, but only when chosen for the heap budget; an application may also need a key-length (or path-length) limit.
• Effect. A VM error instead of the polygon or the declared ParseException. No wrong polygon is returned and no index is touched.
• Realistic input is not at risk. Real GeoJSON is shallow (a MultiPolygon's coordinates are four arrays deep) and uses short keys, so its paths stay short (the formula above); no report in ten years.

LuceneTestCase is only the base class; no randomness is used. The test asserts the declared outcome (one polygon) and only turns OutOfMemoryError into a readable message; ParseException is not accepted as a pass. Lucene's default test heap is 512 MiB (tests.heapsize in TestsAndRandomizationPlugin.java:132), so the gradle command needs no heap option.

Regression test: this same class, or its one method added to TestPolygon; it passes with the recommended fix. It depends on the default 512 MiB test heap, and the margin is small: unfixed code parses from about -Xmx704m (serial collector) or -Xmx928m (G1), so a 1 GiB test heap would already hide the bug. A PR should keep the default heap for this test (or pin it).

cp $REPRO/TestGeoJSONLongKeyNestedArrays.java $LUCENE/lucene/core/src/test/org/apache/lucene/geo/
cd $LUCENE && ./gradlew :lucene:core:test --tests TestGeoJSONLongKeyNestedArrays -Ptests.seed=DEADBEEF -Ptests.asserts=true
# assertions off fails the same way: -Ptests.asserts=false; the default test heap (512 MiB) is part of the repro

# gradle, stock 645d4fe14a20, -Ptests.seed=DEADBEEF -Ptests.asserts=true (trimmed; -Ptests.asserts=false identical)
java.lang.AssertionError: fromGeoJSON of a 751925-char Feature ran out of a 501 MiB heap: java.lang.OutOfMemoryError: Java heap space
    at org.apache.lucene.geo.TestGeoJSONLongKeyNestedArrays.testLongPropertyKeyOver900NestedArrays(TestGeoJSONLongKeyNestedArrays.java:40)
Caused by: java.lang.OutOfMemoryError: Java heap space
    at java.base/java.lang.StringConcatHelper.newArray(StringConcatHelper.java:578)
    at java.base/java.lang.StringConcatHelper.doConcat(StringConcatHelper.java:436)
    at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:422)
    ...
    at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parseArray(SimpleGeoJSONPolygonParser.java:309)
    at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parseArray(SimpleGeoJSONPolygonParser.java:309)
    ... (every Lucene frame shown is parseArray:309)

:lucene:core:test (FAILURE): 1 test, 1  failure

# "501 MiB" is Runtime.maxMemory() for -Xmx512m with the parallel collector of Lucene's test JVMs;
# the standalone runner (G1) prints "512 MiB" and fails the same way, also with -XX:+UseSerialGC; with -Xmx2g it passes.

• Contract. Polygon.java:248-255: "Parses a standard GeoJSON polygon string. The type of the incoming GeoJSON object must be a Polygon or MultiPolygon, optionally embedded under a \"type: Feature\"." It declares only throws ParseException and links the GeoJSON spec, where the value of a Feature's properties is any JSON object (or null).
• The parser's own example (SimpleGeoJSONPolygonParser.java:24-38) is a Feature whose properties hold a nested object, and TestPolygon.testGeoJSONPolygonFeature (:176) tests that shape.
• Properties are meant to be passed over. LUCENE-8964 (#10007, 8.3.0) changed the parser so that string arrays in properties parse instead of failing (TestPolygon.testPolygonPropertiesCanBeStringArrays, :348).
• Nothing needs the full path. A 21-char prefix gives the same answer to every path test; a 600,000-document differential confirmed it, and caps of 20 and 12 chars were caught as different.
• Recent maintainer stance. #16423 (10.6.0, lucene/CHANGES.txt:551): the expressions parser "could throw StackOverflowError on deeply nested expressions ... The new code allows to add a hard limit for nesting (default is 1024) and no longer throws virtual machine errors."
• Nothing found treats the growth as intended (the file's history and tests, #8433, #10007, and the prior-report searches below).

The strongest case for "intended" (built by the intended-behaviour checker and rated moderate by a works-as-designed reviewer, OpenAI GPT-5.6): the parser is deliberately "simplistic" (#8433) and does "minimal parsing" (SimpleGeoJSONPolygonParser.java:47-51), Polygon is @lucene.experimental, nothing promises a memory bound, SECURITY.md leaves limits on untrusted input to the application, the comment at :311 ("This is only used when parsing the \"features\" in type: FeatureCollection") suggests deep content elsewhere was not expected, and LUCENE-6156 (#7218) is a precedent of a maintainer refusing a guard for a recursion error on huge input.

Why it fails: the input is in the documented domain and modest (752 KB; it parses at 2 GiB); the cost comes from a private detail that buys nothing; the usual limits an application would set (about 1 MiB of input, about 1,000 levels) do not prevent it; SECURITY.md itself calls such issues "valid bug reports and hardening suggestions"; LUCENE-8964 answers the :311 comment; and #16423 is eleven years newer than LUCENE-6156. These points bear on severity and labelling, not on whether it is a defect. Verdict: not intended, a minor defect.

One fix was validated in a scratch worktree of 645d4fe14a20; the context-value alternative was not run. A depth guard (the sibling LFV-949's fix) complements it but does not fix this on its own.

A childPath(path, key) helper replaces the four concatenations (:139-153, :309, :312) and keeps at most MAX_PATH_CHARS = 21 chars, one more than the longest constant compared (features.[].geometry, 20 chars). The finder's diff applies unchanged to 645d4fe14a20 (+28/-16 in SimpleGeoJSONPolygonParser.java).

static final int MAX_PATH_CHARS = 21;

/** Returns the (capped) path of a child: key == null means an array element. */
private static String childPath(String path, String key) {
  if (path.length() >= MAX_PATH_CHARS) {
    return path; // already capped; appending does not change the kept prefix
  }
  String full;
  if (key == null) {
    full = path + ".[]";
  } else if (path.length() == 0) {
    full = key;
  } else {
    full = path + "." + key;
  }
  return full.length() > MAX_PATH_CHARS ? full.substring(0, MAX_PATH_CHARS) : full;
}

Trade-offs

• Same answers. A path of 21 chars or more equals none of the constants either way, and startsWith("crs") and isEmpty() depend only on the kept prefix. It must be 21, not 20: at 20, features.[].geometryx would be cut to features.[].geometry (the differential's cap-20 mutant shows exactly that).
• Memory becomes at most 21 chars per level plus the keys themselves, linear in the input. A long key under a short path is still concatenated in full once and then cut (a short-lived copy, not one kept per level).
• Cost of the shortcut: the constant is tied to the longest compared path; a future, longer constant would need the cap raised (the field's javadoc states the 20-char bound it relies on; a PR could add the features.[].geometryx reason for 21 rather than 20).

What the checks validated

Gradle --no-daemon in a scratch worktree of 645d4fe14a20, OpenJDK 25.0.3 (2026-10-31). Stock: the repro fails with assertions on and off. With the fix:

• the repro passes with assertions on and off;
• :lucene:core:test --tests 'org.apache.lucene.geo.*' with seeds DEADBEEF and CAFEBABE: 18 classes, 194 tests, 0 failures, 7 skipped each (TestPolygon 16, TestTessellator 77, TestSimpleWKTShapeParsing 14, TestPolygon2D 16, the repro, ...);
• one gradle invocation of checkGoogleJavaFormat, forbiddenApisMain and ecjLintMain (core) ended BUILD SUCCESSFUL (the log does not record whether each task ran or was up to date).

Earlier, on a9779ef3c193 (identical file): an independent reproducer's 2-test class passes 2/2 with the cap, and a differential of the original against the capped parser on 600,000 random GeoJSON-like documents gives equal outcomes for all of them while catching cap-20 and cap-12 mutants. On 645d4fe14a20 with the cap shadowed in, the 1,000-nested-objects witness and both controls also return their polygon, assertions on and off (the diagram probe). An independent fact check repeated the geo run (194 tests, 0 failures, 7 skipped) and ran the two skipped nightly tessellator tests that call fromGeoJSON (testComplexPolygon42, testComplexPolygon48) with -Ptests.nightly=true: both pass. Not run: the whole :lucene:core:test.

Pass an enum or int state (root, geometry, features, features.[], features.[].geometry, crs, crs.properties, other) to each child instead of a String.

Trade-offs

Constant memory per level and clearer intent; a larger diff that rewrites every path test, so it needs the same differential to show identical behaviour.

The sibling LFV-949's fix throws ParseException beyond 1,000 levels, as #16423 did for expressions.

Trade-offs

Fixes the StackOverflowError sibling but not this: with only the guard, this repro and the finder's 900-level test still fail with OutOfMemoryError. Ship it together with the path cap.

Method: semi-formal (an executed probe first, then a solver model that produced the witness).

• Lead. A hunt planner, looking for siblings of the expressions-parser nesting fix #16423, probed the GeoJSON parser: OutOfMemoryError at 20,000 nested arrays (40 KB) with a 512 MiB heap and at 40,000 (80 KB) with 1 GiB, on a 4 GB thread stack, the depth-squared signal of the path strings. On a default stack the sibling StackOverflowError comes first, so that form is not reachable by default.
• Model. A hunting unit wrote a Z3 model of the live path strings (closed-form lower bound d(75+K) + 3d(d-1)/2 bytes). Its queries found a witness at depth 1,000 or less (Q1), showed that a 1,024-level depth guard does not bound the memory (Q2), that a path-free fix does (Q3, unsat) and a vacuity check (Q4). This produced the long-key, bounded-depth input that separates it from the recursion bug.
• Validation. Heap-threshold bisection on the stock jar matched the model (predicted 253/252/252/103 MiB, measured 255/255/255/105 MiB). The unit reduced it to a public-API JUnit, which was later minimized to the one-test repro shown here.