Stack overflow error when attempting to trace deeply nested object #344

New Issue

adam · 2025-12-30T01:23:42+01:00

adam commented

2025-12-30 01:23:42 +01:00

Originally created by @rohan-datar on GitHub (Sep 10, 2025).

I'm working on creating a minimal reproduction of this, but when trying to trace an object that is deeply nested or uses many imports, trace will throw a stack overflow error. The basic context is that I am attempting to write some tests that run sanity checks on configuration written in pkl. The configuration amends a template that is defined in a remote module and is declared as a dependency is the PklProject file. The template itself imports a number of other modules that define type constraints and some output converters.

The test imports the configuration and defines some fact tests to check the sanity of the configuration. I am using import statements so that I can set some environment values that are otherwise provided at evaluation time. I wanted to trace the amended value to make sure that the values were being set correctly and ran into this error. The interesting thing is that the value can be operated on fine. Running comparisons for the facts works fine even for deeply nested values, but attempting to trace or render the same value produces a stack overflow error.

The error is too long to paste directly so I'm attaching it as a file:
trace_stack_overflow.txt

Originally created by @rohan-datar on GitHub (Sep 10, 2025). I'm working on creating a minimal reproduction of this, but when trying to trace an object that is deeply nested or uses many imports, `trace` will throw a stack overflow error. The basic context is that I am attempting to write some tests that run sanity checks on configuration written in pkl. The configuration amends a template that is defined in a remote module and is declared as a dependency is the `PklProject` file. The template itself imports a number of other modules that define type constraints and some output converters. The test imports the configuration and defines some `fact` tests to check the sanity of the configuration. I am using import statements so that I can set some environment values that are otherwise provided at evaluation time. I wanted to `trace` the amended value to make sure that the values were being set correctly and ran into this error. The interesting thing is that the value can be operated on fine. Running comparisons for the `facts` works fine even for deeply nested values, but attempting to `trace` or render the same value produces a stack overflow error. The error is too long to paste directly so I'm attaching it as a file: [trace_stack_overflow.txt](https://github.com/user-attachments/files/22259043/trace_stack_overflow.txt)

adam commented

2025-12-30 01:23:43 +01:00

@HT154 commented on GitHub (Sep 10, 2025):

Without a repro to look at, my suspicion is there's a circular data reference somewhere in the value. This is valid in Pkl as long as you don't attempt to render the value (including via trace). Your comparisons may not be exercising the specific cycle.

One thing to note: Pkl's stack overflow reporting is heuristic. It tries to determine (from a Java stacktrace) if the overflow happened within Pkl code. When it detects this, you'll get a helpful error showing the cycle in Pkl, but in some cases it may fail to identify the cycle and produce the less helpful Java stack trace like you see here.

@HT154 commented on GitHub (Sep 10, 2025): Without a repro to look at, my suspicion is there's a circular data reference somewhere in the value. This is valid in Pkl as long as you don't attempt to render the value (including via `trace`). Your comparisons may not be exercising the specific cycle. One thing to note: Pkl's stack overflow reporting is heuristic. It tries to determine (from a Java stacktrace) if the overflow happened within Pkl code. When it detects this, you'll get a helpful error showing the cycle in Pkl, but in some cases it may fail to identify the cycle and produce the less helpful Java stack trace like you see here.

adam commented

2025-12-30 01:23:43 +01:00

@rohan-datar commented on GitHub (Sep 10, 2025):

Could this be caused by an import cycle? I'm fairly certain there is one in the module I'm importing, which would explain it. I see #1183 but I've never run into a NullPointerException and afaik there's nothing in pkl itself that disallows circular imports.

@rohan-datar commented on GitHub (Sep 10, 2025): Could this be caused by an import cycle? I'm fairly certain there is one in the module I'm importing, which would explain it. I see #1183 but I've never run into a `NullPointerException` and afaik there's nothing in pkl itself that disallows circular imports.

adam referenced this issue

2025-12-30 01:25:04 +01:00

[PR #344] [MERGED] Eliminate unnecessary use of GregorianCalendar #514

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#344