StackOverflowError when variables contain circular references

[rc2201]

Description

Karate v2 crashes with StackOverflowError when a variable contains a circular reference (an object that directly or indirectly points back to itself).

Additional details- I originally saw the issue when testing the fix for #2870 in 2.0.10.RC1 and saw the note here - https://github.com/karatelabs/karate/blob/main/karate-gatling/src/main/scala/io/karatelabs/gatling/KarateScalaActions.scala#L151, but the issue does not seem limited to the performance tests.

Steps to Reproduce

1. Create a feature file using the snippets below.

Feature: hashCode StackOverflow - circular reference reproduction

  Scenario: Create circular reference in variables
    # Create an object with a self-reference (circular)
    * def obj = { name: 'test', items: [1, 2, 3] }
    * eval obj.self = obj
    # Verify the circular reference exists — this will FAIL if obj.self is not obj
    * match obj.self.name == 'test'
    * match obj.self.self.name == 'test'
    * print 'Circular reference confirmed'

Expected Behavior

1. The test should successfully execute and pass (v1 behavior). Attached is the screenshot from v1 result.

Actual Behavior

1. The test crashes at run time with below stacktrace.

14:16:37.232 [com.intuit.karate.Main.main()] INFO  karate.scenario - Circular reference confirmed
[WARNING] 
java.lang.StackOverflowError
    at java.util.LinkedHashMap.entrySet (LinkedHashMap.java:883)
    at java.util.AbstractMap.hashCode (AbstractMap.java:499)
    at java.util.Objects.hashCode (Objects.java:97)
    at java.util.HashMap$Node.hashCode (HashMap.java:299)
    at java.util.AbstractMap.hashCode (AbstractMap.java:500)
    at java.util.Objects.hashCode (Objects.java:97)
    at java.util.HashMap$Node.hashCode (HashMap.java:299)
    at java.util.AbstractMap.hashCode (AbstractMap.java:500)
    at java.util.Objects.hashCode (Objects.java:97)
   

14:41:56.709 [gatling-1-1] ERROR i.k.gatling.KarateScalaAction - Gatling crashed: j.l.StackOverflowError
java.lang.StackOverflowError
	at java.base/java.util.LinkedHashMap$LinkedEntryIterator.<init>(LinkedHashMap.java:1058)
	at java.base/java.util.LinkedHashMap$LinkedEntrySet.iterator(LinkedHashMap.java:915)
	at java.base/java.util.AbstractMap.hashCode(AbstractMap.java:499)
	at java.base/java.util.Objects.hashCode(Objects.java:97)
	at java.base/java.util.HashMap$Node.hashCode(HashMap.java:299)
	at java.base/java.util.AbstractMap.hashCode(AbstractMap.java:500)
	at java.base/java.util.Objects.hashCode(Objects.java:97)
	at java.base/java.util.HashMap$Node.hashCode(HashMap.java:299)
	at java.base/java.util.AbstractMap.hashCode(AbstractMap.java:500)
	at java.base/java.util.Objects.hashCode(Objects.java:97)

Karate Version

2.0.9

Java Version

25.0.2

Operating System

macOS

[ptrthomas]

Thanks for the report. Partial fix landed in 2b2947a on main.

What was fixed. Json.stringifyStrict (used by * print obj for Map/List values) and Json.toBytes were calling JSONValue.toJSONString from json-smart directly, and json-smart has no circular-reference guard — it infinite-recurses on a self-referencing Map. They now pre-walk with an IdentityHashMap; if a cycle is detected, they substitute back-edges with "#<classname>" markers (same convention as the existing Json.copy(o, true, true)). Non-cyclic values pass through untouched.

If you append * print obj to your repro feature, that path now works — confirmed by a new test that runs your scenario verbatim.

What may not be fixed. Your stack trace is AbstractMap.hashCode recursion, which is a different failure mode than the writer recursion above — it triggers when a cyclic plain LinkedHashMap is put into another HashMap/HashSet/Set.add somewhere. JsObject (the wrapper Karate uses for def obj = {...}) already overrides hashCode/equals to be identity-based to avoid exactly this, so the crash requires the JsObject to first be unwrapped to a plain Map and then re-put somewhere. I couldn't reproduce that on main with your exact feature.

We'll assume this is closed when 2.0.10 ships. If you still hit a stack overflow on 2.0.10, please open a new issue with a way to reproduce — full stack trace including Karate frames, how you invoke Karate (JUnit class? CLI? wrapper?), and karate-config.js if any.

[rc2201]

Thanks @ptrthomas . I did retry it on the RC version and am still seeing the issue. Here is the stacktrace if it gives any further pointers-

13:22:38.169 [com.intuit.karate.Main.main()] INFO  karate.runtime - classpath:karate-config.js processed
13:22:38.171 [com.intuit.karate.Main.main()] INFO  karate.runtime - backed up existing output to: target/karate-reports_20260527_132238
13:22:38.227 [com.intuit.karate.Main.main()] DEBUG karate.runtime - Set runtime log level to: trace
13:22:38.228 [com.intuit.karate.Main.main()] DEBUG karate.runtime - Evaluated target/test-classes/karate-config.js: 59 variables
13:22:38.229 [com.intuit.karate.Main.main()] DEBUG karate.runtime - http log mask active: 3 headers, 0 jsonPaths, 0 patterns
13:22:38.239 [com.intuit.karate.Main.main()] INFO  karate.scenario - {"name":"test","items":[1,2,3],"self":"#java.util.LinkedHashMap"}
13:22:38.239 [com.intuit.karate.Main.main()] INFO  karate.scenario - Scenario completed without print crash
13:22:38.241 [com.intuit.karate.Main.main()] DEBUG karate.runtime - Inherited config from caller
13:22:38.247 [com.intuit.karate.Main.main()] DEBUG karate.runtime - Released lock(s) for scenario: Create circular reference in variables
13:22:38.262 [com.intuit.karate.Main.main()] DEBUG karate.runtime - HTML report written to: target/karate-reports/karate-summary.html
[WARNING] 
java.lang.StackOverflowError
    at java.util.ArrayList.hashCode (ArrayList.java:665)
    at java.util.Objects.hashCode (Objects.java:97)
    at java.util.HashMap$Node.hashCode (HashMap.java:299)

Based on this, the crash seems to be happening AFTER report generation completes. I noticed the performance tests for the above feature also crash with a similar trace shared earlier in the description.

If this is not sufficient, I will try to reproduce and report after the 2.0.10 version is released.

[ptrthomas]

Thanks for the follow-up. Couple of things worth pinning down before we can act on this.

The fix from 2b2947a25 is doing its job. Your print output "self":"#java.util.LinkedHashMap" is exactly our cycle-marker — * print obj is no longer the failure site.

The new stack is the other failure mode I called out in the commit message — HashMap$Node.hashCode → Objects.hashCode(value) → ArrayList.hashCode → … is hashCode recursion through a cyclic plain LinkedHashMap/ArrayList graph, not writer recursion. It requires the value to have been unwrapped out of JsObject (which has identity-based hashCode/equals) into a raw LinkedHashMap, and then put into a HashMap/HashSet whose hash later gets computed. We traced the v2 report-gen pipeline end-to-end:

• HTML report (HtmlReportWriter.inlineJson → StringUtils.formatJson) has its own IdentityHashMap cycle guard and emits "[Circular]" on back-edges — no hashCode() calls on user values.
• FeatureResult.toJson() / ScenarioResult.toJson() are purely structural (status, timings, step text, embeds). The only fields that ever re-emit user data are callArg (called features) and exampleData (outlines).
• Ran your exact feature through Runner.parallel(1) with HTML + Cucumber JSON + JUnit XML + JSONL all enabled on main — passes, no SOE.

So the crash isn't in our report generator. Two things in your log tell us the reproduction you posted isn't the actual reproduction:

1. DEBUG karate.runtime - Inherited config from caller only fires in ScenarioRuntime.inheritConfigFromCaller, and that path is only reached when this scenario was invoked via call/callonce. The 7-line feature you posted has no call. So the failing run is doing more than what you've shared.
2. Evaluated target/test-classes/karate-config.js: 59 variables + http log mask active says you have a non-trivial karate-config.js and likely HTTP traffic. Any of that could be the site that hashCodes the cyclic graph.

The stack trace itself is also unusable as posted — JDK 25 truncates StackOverflowError at 1024 frames and we see zero Karate frames, just the JDK loop. We can't pin the call site without seeing what was on top of that loop.

To make progress we need a complete, runnable reproduction. Specifically:

• The full feature file (the actual one — including any call, callonce, or karate.call(...) steps).
• The full karate-config.js (or a minimal copy of it that still reproduces).
• The complete pom.xml (we suspect a Maven plugin in your build — maven-cucumber-reporting or similar — may be the one calling hashCode after Karate hands the result over; that would explain why the SOE shows up after HTML report written to: … with [WARNING] and no Karate frames).
• The full stack trace with -XX:MaxJavaStackTraceDepth=1000000 so the frames above the JDK loop are visible.

Ideally, fork https://github.com/karatelabs/karate-todo, add your feature + config + any extra reporting plugins you use, push it, and link the repo here. Anything short of that will leave us guessing — we don't currently see this crash on `main` with the inputs you've provided, and the report-gen code path is clean.

We'll keep the milestone on 2.0.10 in case the repro shows something we own, but without a reproduction we can run, this would otherwise close once 2.0.10 ships.

[ptrthomas]

v2.0.10 released