Debugging infinite loop

GoJS
1

Hi, I am occasionally running into this infinite loop while dragging nodes:

go.js?body=1:1007 Uncaught RangeError: Maximum call stack size exceeded 
v.defineProperty.b @ go.js?body=1:1007 
R.isVisible @ go.js?body=1:1431 
W.isVisible @ go.js?body=1:1613 
S.isVisible @ go.js?body=1:1483 
S.findVisibleNode @ go.js?body=1:1482 
W.isVisible @ go.js?body=1:1613 
S.isVisible @ go.js?body=1:1483 
S.findVisibleNode @ go.js?body=1:1482 
W.isVisible @ go.js?body=1:1613 
S.isVisible @ go.js?body=1:1483

I expect this is particular to something I’m doing somewhere in application code, but the recursion is all within the go.js library, as you can see. Any pointers on how I might begin to debug this?

2

What version of GoJS are you using?

Can you show us a screenshot of a simple diagram and indicate which node(s) you can drag to cause this infinite(?) recursion to happen? The simpler diagram that you can reproduce the problem in, the better for us to be able to track down the problem.

3

This is with go.js version v1.6.22.

In my app, this can happen with a simple map with just two nodes and a link between them, but I am overriding a bunch of functionality, including a Link subclass with its own computePoints, a custom LinkReshpaingTool, and a custom DraggingTool, etc.

It is hard to reproduce consistently, but I will see if I can boil it down to a simple test case.

4

Well, your custom LinkReshapingTool probably is unrelated to the problem, because it is not active when the user is dragging a node.

I don’t know how you have customized the DraggingTool, and it is entirely possible to have it cause side-effects that do not settle down quickly. What changes have you made to its behavior?

But I’m wondering if the problem is with your override of Link.computePoints. If you set Layout.isRealtime to false on your Layout, does the problem still happen? EDIT: hmmm, on further thought, this is unlikely to be the problem.

5

Looks like this has to do with a link’s labelKeys referring to a node which is also specified as one of it’s to/from nodes. Minimal example:

var $ = go.GraphObject.make;  // for conciseness in defining templates

myDiagram = $(go.Diagram, "myDiagramDiv");

myDiagram.groupTemplate =
  $(go.Group, "Auto",
    $(go.Shape, "RoundedRectangle", { strokeWidth: 3, fill: "white"}),
    $(go.TextBlock,
      { margin: 8 },
      new go.Binding("text", "text"))
  );

  myDiagram.model = new go.Model.fromJson('{"class":"go.GraphLinksModel","linkLabelKeysProperty":"labelKeys","nodeDataArray":[{"key":1,"text":"New Idea","isGroup":true,"loc":"136 376"},{"text":"Idea","isGroup":true,"key":-2,"loc":"263 -32"},{"text":"Relationship Idea","isGroup":true,"category":"LinkLabel","loc":"42 -17","key":-3}],"linkDataArray":[{"type":"noArrows","from":1,"to":-2,"labelKeys":[-2]}]}');

Edit fiddle - JSFiddle - Code Playground (load with the error console open…)

Notice how the link there has -2 as the value of its to property, as well as the value of its labelKeys property.

That situation doesn’t really make sense to begin with, and we’re not arriving there on purpose, so I’ll have to track down where we’re going astray in our app. But at the same time, I would propose that go.js could handle this more gracefully?

6

Thank you very much for narrowing down the problem to a simple reproducible example.

We have fixed this bug for the next release, 1.6.24 and 1.7.0-beta3. I do not know when those releases will happen (next week?), but since you do not need to support such a nonsensical organization of nodes and links, I assume you won’t need this bug fix very soon.

7

Yes, that’s right. Thanks.