jScope attempts to resolve otherwise valid recursive node

[benjysmith]

Affiliation
OpenStar Technologies

Version(s) Affected
Alpha 7.157.2 for both client and server.

Platform(s)
Ubuntu 22.04 (Server) and Mac OS Tahoe 26.3 (Client)

Installation Method(s)
Server installation method: Installed with apt from MDSplus Debian repository.
Client installation method: brew install from https://github.com/dgarnier/homebrew-plasma

Describe the bug
When displaying signals with a cyclic relationship in jScope (when the signals can be queried normally through other interfaces), the connection to the MDSplus server is dropped, and the server crashes with a segfault.

To Reproduce

1. Set up a signal node which has a cyclic relation to itself, but which alternates between the value and the dimension. The example Python script below shows one way of doing this:

from MDSplus import Tree, Signal, Float32Array

shot = 260218918
tree = Tree('junior', shot)

raw_times = Float32Array([0.0, 1000.0, 2000.0])
values = Float32Array([1.0, 2.0, 3.0])

times = Signal(tree.TEST1, None, raw_times)
tree.TEST1.record = Signal(values, None, times)

tree.close()

# Check that we can successfully query the data and the dimension of the node
tree = Tree('junior', shot)
print(tree.TEST1.record)
print(tree.TEST1.data())
print(tree.TEST1.dim_of().data())
print(tree.TEST1.dim_of().dim_of().data())

tree.close()

2. Open jScope, running locally on the client machine, connected to the remote server

3. Plot the signal node in jScope (see screenshot A)

4. When clicking "Ok" or "Apply" in the wave setup dialog, jScope will freeze for a few seconds, then display a connection lost error (also shown in screenshot A)

Expected behavior
Expect jScope to show the signal, as it does when explicitly writing DATA(<signal node>) in the Y field, and DIM_OF(<signal node>) in the X field (see screenshot B).
At the very least, if jScope cannot handle the cyclic node, then it should display a clear error message, stating that the node contains a cyclic reference which the user should fix, and the MDSplus server should not crash.

Screenshots
Screenshot A: The signal setup to reproduce the issue, after clicking the "Apply" button

Screenshot B: Explicitly writing DATA(.TEST1) and DIM_OF(.TEST1) do not cause the issue

Screenshot C: On the server machine, the mdsip server responsible for the connection crashes with a segfault

Additional context
What is interesting about this particular example, is that typical usage of the signal will not reveal the cyclic relationship.
Querying the data will simply return the values stored in the node (or the expression applied to the raw data values), and querying the dimension will require evaluating the data of the original node, which in theory only requires evaluating the data values stored in the node, preventing an infinite cycle.
The issue only arises when an attempt is made to resolve the entire expression tree, which it seems is a feature unique to jScope, as I am unable to reproduce this issue when querying data through the Python interface, the C interface, or with tdic directly.

[mwinkel-dev]

We briefly discussed this issue during today's team meeting. @joshStillerman conjectures that perhaps the recursion is blowing out the Java stack. We will conduct experiments with Java's -Xss command line argument when we work on reproducing this bug.

[mwinkel-dev]

Hi @benjysmith -- Thanks for the clear instructions. I was abled to reproduce the bug with ease.

It is interesting that this bug crashes the mdsip process and that it only happens with Java. Some quick experiments with Java's -Xss option didn't make much difference.

As @joshStillerman has explained, the various APIs eventually hand off the evaluation to the mdsip server's TDI, which in turn has the logic for evaluating the recursion. Thus, one would expect this bug to be a problem with all APIs. It is odd that the bug is just with jScope / Java.

This issue will be updated when the root cause of the problem is identified.

[GabrieleManduchi]

The reason for the different behavior between jScope visualization and direct access via MDSplus (e.g. tree.test1.data()) is due to the fact that when jScope accesses a signal it checks if the node is an expression containing segmented data. In this case, jScope applies a resampling policy using SetContext. The check for segmented data is carried out by recursively navigating into the expression structure in order to reach a referenced segmented node (if any). In this case, there is a recursive reference in the expression itself (and indeed this is an inconsistent definition), and so the recursive search for segmented nodes enters a loop steadily allocating stack frames until it runs out of memory and the mdsip server launched by jScope as a subprocess crashes. A fix could be added in the recursive procedure for checking for segmented node (in mdsmisc) by verifying possible reference loops.

[mwinkel-dev]

Hi @GabrieleManduchi -- Thanks for the explanation. Much appreciated!

[joshStillerman]

Couldn’t you just use getNumSegments() instead ? Joshua Stillerman Research Engineer MIT Plasma Science and Fusion Center ***@***.***

…

On Feb 27, 2026, at 3:10 AM, GabrieleManduchi ***@***.***> wrote: GabrieleManduchi left a comment (MDSplus/mdsplus#3029) <#3029 (comment)> The reason for the different behavior between jScope visualization and direct access via MDSplus (e.g. tree.test1.data()) is due to the fact that when jScope accesses a signal it checks if the node is an expression containing segmented data. In this case, jScope applies a resampling policy using SetContext. The check for segmented data is carried out by recursively navigating into the expression structure in order to reach a referenced segmented node (if any). In this case, there is a recursive reference in the expression itself (and indeed this is an inconsistent definition), and so the recursive search for segmented nodes enters a loop steadily allocating stack frames until it runs out of memory and the mdsip server launched by jScope as a subprocess crashes. A fix could be added in the recursive procedure for checking for segmented node (in mdsmisc) by verifying possible reference loops. — Reply to this email directly, view it on GitHub <#3029 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABY5AZID3MO33MKGMSLRAF34N73XXAVCNFSM6AAAAACWAARQ3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNZRGQ2DONJSG4>. You are receiving this because you were mentioned.

[GabrieleManduchi]

The reason is that in most cases in jScope a segmented node is not referenced directly, rather withing an expression. For this reason it is necessary to dig into the expression tree in order to discover whether a segmented node is referenced.

[joshStillerman]

We should consider a chunk of C-Code to traverse the expression. There is code in TCL show data that does the traversal.

[GabrieleManduchi]

It is already there: recIsSegmented() in ScopeUtilities.c of mdsmisc

[joshStillerman]

So does it need a recursion break - that stops if it either loops around (better) or goes too deep (what tdi currently does)

[GabrieleManduchi]

indeed. I can work on it in a couple of days

[GabrieleManduchi]

I have just issued a PR with a fix