Stackoverflow exception during mouse down and drag

JGo
1

We ran into a problem of stackoverflow exception inside JGOView dragSetData when it’s trying to do writeObject to an outputstream.<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Here is what happened. We have an application that allows user to draw their workflow diagram which uses JGO SWT 5.1. When an user creates a graph with more than 800 elements (node, route/link, branches, etc), and he tries to drag one of the node to a different position on the canvas, the mouse down event is captured, followed by drag enter, drag move, etc, then when it got to dragSetData, an stackflow overflow exception happens. This looks like it has something to do with the failure of object serialization during DND. The end result is after exception happens, all the other mouse events that are supposed to happen are discarded (for example mouse up, etc), then the application is in a weired stated and seems to be stucked in mouse down => drag state. If I reduced the graph elements to about 400-500, the application works correctly.

Here are my questions:

1) any body runs into similar situation before, and how they fix it?

2) does increasing the stack size for Java –Xss flag help in this case (how big should it be??)

3) why does mouse move event in JGO results calling internal / native DND which is perform the serialization

Any help will be appreciated. Thanks.

-Betty

2

If you upgrade to version 5.21, you probably won’t have that problem.

All “real” drag-and-drops do serialization of the data. I’m not sure why that is always necessary, but it makes sense that it is sometimes necessary (for example between applications), and perhaps it is always done for consistency’s sake. (This is true both for Swing and for SWT.)

3

Thanks for your prompt reply. We have to issue a patch to customer, so we can’t really upgrade to 5.2.1. Is there any way around it? Thanks :)

4

You could try avoiding “real” drag-and-drop by calling JGoView.setDragEnabled(false). That’s assuming that you don’t need to drag out of the view into some other control. But there are other side-effects to not using real drag-and-drop, so you’ll have to test it.

5

In the same view, we do have drag and drop compenents (toolbar and some tree to drag some stuff onto the canvas). I try out your suggestion, I can’t really disabled the drag b/c I can’t really tell when it’s a real drag and drop or not. Do you know if there is any other info I can use to tell when it’s a mouse drag move or when is a read drag and drop or any suggestion where to turn off this flag?

6

Set it when you initialize the JGoView.

The view can continue to accept drag-and-drops from other controls if you call JGoView.setDropEnabled(true).

7

So I am a little bit confused. Can you elaborate a little bit on what exactly is happening when I setDragEnabled(false). Does that mean I still drag and drop from other control as long as DropEnabled is true? The flag for dragEnabled will turn off the serialization part ?

8

I just did a download of 5.2.1 and the problem still exists on our end. So I did try to turn off DragEnable during init of JGOView subclass, and it seems to work fine even with drag and drop from other controls.
Walter, can you tell me what exactly are we turn off / skip when DragEnable is set to false?
Thanks.

9

JGoView.setDragEnabled(false) removes the DragSource from the view, and causes the JGoView methods that implement DragSourceListener to do nothing.

You can see what it does by looking at the definitions of those and related methods in JGoView.java.

10

I see. So what’s changed in V5.2.1 and make you think that the latest version of JGO 5.2.1 can fix this serialization stack overflow problem ? Thanks again.

11

We changed JGoView.dragSetData to serialize a copy of the selection in a separate JGoDocument, instead of serializing the selection directly. The latter would cause the whole document to be serialized, which is overkill for drag-and-drop purposes.

Now why serializing your (whole) JGoDocument would cause a stack overflow, I don’t know. We haven’t done anything to affect that behavior. It seems that your stack overflow is not dependent on the size of the document after all. I suppose you could test this by explicitly (programmatically) serializing your document when it has 1000+ elements in it.

12

Walter, we were doing more testing now, and we found out that we have exactly the same problem of doing copy and paste of a group of nodes within a large graph. Same stackoverflow exception, it looks like it’s related to a similar serialization. So turn off setDragEnable(false) is not good enough for the situation.

13

OK, so the problem is inherent in doing the serialization of your document, not in how we implement drag-and-drop or copy-and-paste, both of which require serialization.

If you increase the stack size, do you ever encounter the problem? Is the needed stack size proportional to the longest path in your graph?

14

our app runs inside eclipse (bunch of plugins), and we packaged a workbench.exe and a INI file, I did try to add -Xss30M to te file. It doesn’t seem to help at all. I do noticed some of our objects we subclass from JGO class have collection, hashmap, some images (ImageData - transient). I am really running out ideas on how to fix. I put hte following code in our app when we initiatlize the JGOView, and of course it blows up with stackoverflow exception:

FileOutputStream fos = null;

ObjectOutputStream out = null;

try

{

fos = new FileOutputStream("C:/testLargeMap.ser");

out = new ObjectOutputStream(fos);

out.writeObject(this.getDocument());

out.close();

}catch(IOException ex)

{

ex.printStackTrace(); }

15

Can you provide excerpts of all the interesting parts of the stack trace? Are only JGo objects involved? Are there any objects being serialized unexpectedly?