StackOverFlow exception due to large net

[Peter Haahr Taankvist]

Sometimes when working with a large net where many places/transitions are on top of each other with arcs between them we get a stackoverflow exception.

How to reproduce:
1. Import attached PNML file in tapaal 3.6.0
2. Hover the namelabels of the places/transitions such that the cursor changes
3. Hover the many places/transitions
4. The cursor will not update, you will get a stackoverflow exception and the gui will break/slow down very much

It might have something to do with updating the many arc end points, but it only happens for me when i hover the namelabels first.

[Jiri Srba (srba)]

I cannot reproduce this on Mac (or maybe I am not doing the right movements), but I had
similar problem with stack size on mac previously, that I fixed in the run script by
calling java with

 java -Xmx6144M

Can you try to see if this will fix the problem on linux?

[Peter Haahr Taankvist (ptaank)]

This is already done when using ./run-tapaal-j7.sh and the error still occurs

[Jiri Srba (srba)]

Does further increasing the stacksize by changing the swithc in the run-tapaal-j7.sh solve the problem?

[Peter Haahr Taankvist (ptaank)]

-Xmx6144M actually increases the heap size as far as i can tell. -Xss16M increases the stack size. Using this command fixes the StackOverflowError.

It should still be noted that the gui is not very responsive when working with nets this large. Anytime I try to move anything my CPU goes to 25% (maximum allowed for a single program) and the gui freezes for a long time.

The bug happens when a lot of places and transitions with arcs between them are on top of each other. Then when you hover the arc they all want to show their arc points at the same time causing the stack overflow. Maybe there is a way to prevent this from happening?

[Kenneth Yrke Jørgensen (yrke)]

the performance of the nets will properly decrease in the number of elements (especially arcs) as it internally is iterating all elements on any gui event. This is part of what I try to address in the dev branch. I this the overflow could indicate that there is an update "loop" somewhere there different elements triggers unneded updates of other elements, I know this is the case at least some places for drawing arcs.

[Kenneth Yrke Jørgensen (yrke)]

Seems like its swing that are not very happy if you place a lot of elements in the same location:

From: container.class
final Component findComponentAtImpl(int x, int y, boolean ignoreEnabled) {
        if (!this.contains(x, y) || !this.visible || !ignoreEnabled && !this.enabled) {
            return null;
        } else {
            Component lightweight = null;
            Iterator var5 = this.component.iterator();

            while(var5.hasNext()) {
                Component comp = (Component)var5.next();
                int x1 = x - comp.x;
                int y1 = y - comp.y;
                if (comp.contains(x1, y1)) {
                    if (!comp.isLightweight()) {
                        Component child = getChildAt(comp, x1, y1, ignoreEnabled);
                        if (child != null) {
                            return child;
                        }
                    } else if (lightweight == null) {
                        lightweight = getChildAt(comp, x1, y1, ignoreEnabled);
                    }
                }
            }

    private static Component getChildAt(Component comp, int x, int y, boolean ignoreEnabled) {
        if (comp instanceof Container) {
            comp = ((Container)comp).findComponentAtImpl(x, y, ignoreEnabled);
        } else {
            comp = comp.getComponentAt(x, y);
        }

        return comp == null || !comp.visible || !ignoreEnabled && !comp.enabled ? null : comp;
    }

Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.getChildAt(Container.java:2711)
 at java.awt.Container.findComponentAtImpl(Container.java:2697)
 at java.awt.Container.findComponentAt(Container.java:2667)
 at java.awt.Container$1.findComponentAt(Container.java:268)
 at sun.awt.GlobalCursorManager._updateCursor(GlobalCursorManager.java:193)
 at sun.awt.GlobalCursorManager.updateCursorImmediately(GlobalCursorManager.java:95)
 at sun.awt.windows.WComponentPeer.updateCursorImmediately(WComponentPeer.java:683)
 at java.awt.Component.updateCursorImmediately(Component.java:3145)
 at java.awt.Component.show(Component.java:1646)
 at java.awt.Component.show(Component.java:1671)
 at java.awt.Component.setVisible(Component.java:1623)
 at javax.swing.JComponent.setVisible(JComponent.java:2644)
 at pipe.gui.graphicElements.ArcPath.showPoints(ArcPath.java:439)
 at pi...

[Kenneth Yrke Jørgensen (yrke)]

Might be realted to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6480024