Stack Overflow when using too many Layouts

[hedgesda]

So I've run into some troubles recently trying to create a custom grid widget. I want the ability to create an unknown amount of Rows (HLayouts). Each Row will have a fixed number of Labels. However, I get a stack overflow when I try to add too many rows. I've been able to reproduce this in a simple app. First I will show code that works:

private class RowDisplay extends VLayout {
	public RowDisplay() {
		RowDisplay.this.setWidth100();
		RowDisplay.this.setHeight(20);
			
		HLayout grid = new HLayout();
		grid.setMembersMargin(1);
		for (int i=0; i<31; i++) {
		     Label slot = new Label("Test " + Integer.toString(i+1));
		     grid.addMember(slot);
		}
			
		addMember(grid);
	}
}
	
public void onModuleLoad() {  

	  // create a grid of Labels
	  VLayout rows = new VLayout();
	  rows.setMembersMargin(1);
	  for (int i=0; i<10; i++) {
	      rows.addMember(new RowDisplay());
	  }
	  
	  // add a VLayout Layer
	  VLayout layer_1 = new VLayout();
	  layer_1.setWidth100();
	  layer_1.setHeight100();
	  // add the row
	  layer_1.addMember(rows);
	  
	  layer_1.draw();
 }

Now, if I need to increase the rows to say 50, I get a stack overflow on line 2698

for (int i=0; i<50; i++) {
    rows.addMember(new RowDisplay());
}

I think I'm setting this up correctly, but maybe I'm missing something? Should I increase the memory (current set at -Xmx600M)? I'm not sure what the work around would be, an html table maybe? Thanks.

[mihai007]

are you getting this during compilation or in hosted mode preview? and what's the gwt version?

[hedgesda]

I get this in hosted mode preview, however, nothing is displayed other than the stack overflow error message. I've tested this using both GWT 1.5 and 1.6 (using the 1.5 com.google.gwt.dev.GWTShell method) -- both claim the stack overflow occurs at line 2698.

Thanks for the reply.

[smartgwt.dev]

Do you see the message in web mode?

[hedgesda]

The error message I get in web mode is a "Stop running script?" message (please see attachment). Once I select Yes to continue, the page is drawn blank. I've attached a screen grab of the hosted mode error message as well.

[london]

I get this in hosted mode preview, however, nothing is displayed other than the stack overflow error message. I've tested this using both GWT 1.5 and 1.6 (using the 1.5 com.google.gwt.dev.GWTShell method) -- both claim the stack overflow occurs at line 2698.

Thanks for the reply.

I see exactly the same problem with the stack overflow at line 2698. I came to the same conclusion that the problem was caused by reaching a limit on the number of nested layouts(mostly VStacks/HStacks).

To work around I temporarily deactivate some of my content in hosted mode. This makes development difficult.

Any guidance on this problem would be appreciated.

[mihai007]

first: dont' click yes, click no and allow the application to run.
if it works without errors (besides this warning message) then all you have to do is create some of the layouts inside a timer.

[london]

first: dont' click yes, click no and allow the application to run.
if it works without errors (besides this warning message) then all you have to do is create some of the layouts inside a timer.

Does it matter when the timer is scheduled to kicked off? or is it just that needs to be in a seperate thread so 1ms will do?

What should go in the timer, the contruction of the layout(hstack etc) or the adding of the members?

[mihai007]

this is an IE bug, the solution is as I said, create half of the layouts then a timer of 1ms for the rest of them. This way IE won't think that the script is in some kind of infinite loop.

The point is to use a timer, it does not matter if on the contruction of the layout or ading it's members...
See how it makes better sense...

[london]

See how it makes better sense...

That's funny.

It doesn't make any sense! Presumably you've chosen "half the layout" abitrarily.


I have no idea why what you suggest would work. Not saying it doesn't work.

Just that, randomly breaking the layout down into segments and putting in timers is not doing much for code maintainability. Next person who looks at it going to be scratching their heads. And if any code is moved around it's potentinally going to start breaking again.

Surely there is more scalable solution to this.

[sjivan]

Trying to create 1650 layouts / widgets in a for-loop is going to take time. This is why raw html is used for ListGrid cells rather than nested layouts. If you can describe in further detail what you're trying to build perhaps an alternate suggestion can be made.

Sanjiv

[hedgesda]

Sanjiv,
Thanks for the reply and sorry for the long delay in my reply.

At first, we (my co-developers in my company) ran into this issue when trying to create a dynamic grid application for a project. The grid would contain any number of rows (usually 16). Each row has 32 cells that need to represent a state by a color (red for on, green for good, etc). These cells could be represented by Imgs and would be roughly 16 x 16 pixels. At any time, the state of the grid (each row, each cell) could change (showing a different color). Further, each row needs to ability to expand (or slide down) to display a panel of info beneath (and could dynamically change when a cell is selected or an update comes in).

This problem began to pop up more and more however. In the project mentioned above, the grid app is a "widget" or "gadget". Our program takes advantage of the Portal Layout and aims to be modular for the applications that will be displayed (sorta like iGoogle or MyYahoo). Now, since each widget extends Layout and contains many Layouts, the stack overflow message pops up anytime we try to include just a few Portal Windows.

Worst, and the reason my company will probably choose to go w/ GXT. I created a similar stress test (see my original post for code) in GXT. Although (extremely) slow, there were no funky messages popping up in hosted or web mode. Since we're ultimately developing this for customers, we won't always be able to direct them away from using IE (which seems to be the real culprit behind all of this).

As an aside, we really enjoyed gwt-ext when used in our prototypes. Now that we're ready to move to real production (and pay for licences :), we wanted to follow Sanjiv and use smartGWT, however, this issue seems to be a huge stumbling block and may be enough to direct us towards gxt.

[mihai007]

Well I read on the net that antivirus could also cause the stack overflow in IE (especially norton).

If the cause is also the slow script warning, that can be disabled in windows registry:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\Styles]
"MaxScriptStatements"=dword:ffffffff      

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Styles]
"MaxScriptStatements"=dword:ffffffff

Make a backup before editing registry just to make sure.

Anyway if you can't move clients away from IE, a registry edit could help at least with the slow script warning issue...

[hgaglani]

It may be irrelevant to ur problem but if the widgets are causing a Stack Overflow then u cud try increasing the Stack frame size by passing -Xss4098K alongwith JVM options... or even something larger based on ur application..

This solved a StackOverflow issue that I faced.. Not sure if the underlying problem was the same.. but worth a shot..

ATB,
Hetal

[Isomorphic]

@hedgesda We've built a very similar widget for our life sciences customers in the past (does this happen to be assay result visualization?). You've simply taken the wrong approach: base it on a ListGrid and it's very, very fast.

No idea why you ended up with a stack overflow in one technology vs just a really sluggish experience in the other, but the right solution is to deliver a fast UI, not something that barely works :)