Maximum call stack size exceeded

[ntazelaar]

Hello,

We are currently in the process of researching the possibilities of your library Vis.js to draw network diagrams. We developed a small sample application that serves as a proof of concept to demonstrate that it is possible to achieve what we want with your software, so that we can decide if we want to use it in one of our future projects.

We are currently experiencing problems with the Vis.js library when using it on an embedded platform.
On any other platform we've tried it seems to be working just fine.
The error we keep encountering when opening our sample page on our browser is as follows:

Uncaught RangeError: Max call stack size exceeded.

This results in an empty canvas. The nodes and edges seem to exist in the canvas, but they are not visible.
To get a view of the whole call stack see the image below.

This problem is not only restricted to our sample application. Opening any other network diagram example that is available on your website gives the same problem. First we thought it might be an issue with HTML5 canvas support in our browser but this was not the case, as it seemed that any other HTML5 canvas drawing could be opened successfully.

I managed to overcome this partly by using a trick that increases the stack size in our browser. However, this only works sometimes and very random. Setting the stack size at a high enough value so that our sample application works makes the page crash sometimes.
Comparing the default stack size of the Chromium browser on our embedded device it shows that there is not such a big difference.

Another way that I managed to avoid this problem is by disabling the physics engine of Vis.js.
This is not desirable however. We would like to keep the physics engine because it looks very nice.

Our embedded platform is based on an ARM7 architecture.
The OS installed on our platform is Fedora21:

We are using a build of the Chromium browser that we built ourselves from the original sources. More info below:

Chromium 48.0.2564.116 (Developer Build) (32-bit)
Revision ba6eb95383b3c41f6b91ce448bdc2bd3e39e1b8b
OS Linux
Blink 537.36 (@700a0e589ecfa7e0f65cace17e2f75470c4adf9d)
JavaScript V8 4.8.271.20
Flash (Disabled)
User Agent Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Command Line /var/lib/chromium//chrome --user-data-dir=/root/chromiumprofile/ --flag-switches-begin --flag-switches-end chrome://version
Executable Path /var/lib/chromium/chrome
Profile Path /root/chromiumprofile/Default
Variations 775ebbd7-3f4a17df
4ea303a6-3f4a17df

I hope I have provided you with enough information to get a clear understanding of the problem.
I look forward to working together with you in resolving this issue.

Kind Regards,

Nick Tazelaar

[AlexDM0]

Hi,

The physics allocation algorithm is recursive so a certain stack size is required. How big depends on the amount of nodes but normal desktop distributions have no issues with this unless a position is NaN.

If you cannot reproduce this in a normal browser than I cant really help you other then suggesting the repulsion physics model. It doesnt build the tree but is much much slower.

Regards

[AlexDM0]

Is this still an issue?

Regads

[patrickmcelwee]

I believe this is a duplicate of #1868 and #1625

[MrSaints]

If anyone else encounters this issue, be sure to check your x and y fields. In my case, it was set to null, and caused the error mentioned in this issue. Simply setting it to 0 resolved the issue.

[mojoaxel]

If anyone else encounters this issue, be sure to check your x and y fields. In my case, it was set to null, and caused the error mentioned in this issue. Simply setting it to 0 resolved the issue.

@MrSaints It would be great, if you could create a very simple example to reproduce this and create a new issue for that. That should not be the case! We need better error-handling here.

[mojoaxel]

duplicate of #1625