Safari 5 - (RangeError): Maximum call stack size exceeded

1,100 views
Skip to first unread message

Pascal

unread,
Jun 9, 2010, 10:18:11 AM6/9/10
to Google Web Toolkit
For both gwt 2.0.2 and 2.0.3 some of our users that have upgraded to
Safari 5 are seeing this error. This is a vanilla GWT application (no
external library). This is happening in web mode. Everything works
fine in Safari 4 (and all other browsers). Also, some of our Safari 5
users are not seeing the error.

This is the exact javascript error from the browser.

com.google.gwt.core.client.JavaScriptException: (RangeError): Maximum
call stack size exceeded.

Anybody else seeing this? It seems to be a problem with the
serialization.

Pascal

Pascal

unread,
Jun 9, 2010, 11:11:39 AM6/9/10
to Google Web Toolkit
When we try to run dev mode to get a better stack trace, everything
works fine. Could it be a change in the javascript engine in safari 5
that's causing this error?

Any insights?

Regards,

Pascal

Chris Conroy

unread,
Jun 9, 2010, 3:05:38 PM6/9/10
to google-we...@googlegroups.com
Yes, others are hitting this, and it looks like a bug in the Safari 5
Javascript Core.

> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

--
Chris Conroy
Software Engineer
Google, Atlanta

matthew jones

unread,
Jun 9, 2010, 3:06:12 PM6/9/10
to Google Web Toolkit
It seems to be 32bit safari related... running in rosetta or on SL in
64bit clears the issue up for us.

dunha...@gmail.com

unread,
Jun 9, 2010, 7:31:22 PM6/9/10
to Google Web Toolkit
This is occurring for us in the Arrays.mergeSort() code. A reduced
testcase (which looks like the binarySearch code) is in the webkit bug
tracking system at:

https://bugs.webkit.org/show_bug.cgi?id=40355

It appears that in some complex expressions the right shift operator
is not evaluating correctly. Assigning the result of the right shift
to a temporary variable and then using it appears to make the problem
go away.

As a temporary fix, we're patching Arrays.java:mergeSort() to assign
the result of the right shift to a temporary variable before using it.
If you're using binary search you'd need to patch those functions as
well. It's a bit of a hack, but it seems to work. I've included our
patch below, in case it is helpful to someone.


diff --git a/super/com/google/gwt/emul/java/util/Arrays.java b/super/
com/google/
index 89dcc33..b7ba6fa 100644
--- a/super/com/google/gwt/emul/java/util/Arrays.java
+++ b/super/com/google/gwt/emul/java/util/Arrays.java
@@ -1322,7 +1322,8 @@ public class Arrays {
// recursively sort both halves, using the array as temp space
int tempLow = low + ofs;
int tempHigh = high + ofs;
- int tempMid = tempLow + ((tempHigh - tempLow) >> 1);
+ int half = length >> 1;
+ int tempMid = tempLow + half;
mergeSort(array, temp, tempLow, tempMid, -ofs, comp);
mergeSort(array, temp, tempMid, tempHigh, -ofs, comp);

DenNukem

unread,
Jun 15, 2010, 7:12:23 PM6/15/10
to Google Web Toolkit
So did you end up rebuilding the GWT itself? Where do I start to apply
this patch?

On Jun 9, 4:31 pm, "dunhamst...@gmail.com" <dunhamst...@gmail.com>
wrote:

pash7ka

unread,
Jun 22, 2010, 2:30:43 PM6/22/10
to Google Web Toolkit
There is an Issue 4393 about this bug.

I've applyed dunhamsteve's patch and also in all binarySearch()
functions in Arrays.java and Collections.java changed:
- final int mid = low + ((high - low) >> 1)
+ final int length = high - low;
+ final int half = length >> 1;
+ final int mid = low + half;

and just repacked gwt-user.jar replacing those files.
This worked for me.

Pascal

unread,
Jun 22, 2010, 9:52:23 PM6/22/10
to Google Web Toolkit
Hi,
Has the workaround been included in the codebase somewhere? Is there a
chance that there will be a point release soon?

Regards,

Pascal

Thomas Broyer

unread,
Jun 23, 2010, 6:50:29 AM6/23/10
to Google Web Toolkit


On 23 juin, 03:52, Pascal <zig...@gmail.com> wrote:
> Hi,
> Has the workaround been included in the codebase somewhere? Is there a
> chance that there will be a point release soon?

There's been a change at the compiler-level instead:
http://code.google.com/p/google-web-toolkit/source/detail?r=8300

I don't think we'll see a 2.0.4 though, I guess the plan is to just
ship it with 2.1 when it'll be ready.
(remember last year when IE8 finally went out? –there was a workaround
though– or Safari 4 and its "expression too deep" errors? or Firefox
3.5 and its regression re. mouse events on scrollbars?)
See http://code.google.com/p/google-web-toolkit/issues/detail?id=3455,
http://code.google.com/p/google-web-toolkit/source/detail?r=5641
This was all fixed in the next release, but it took some time between
the report, the fix, and then the release.

Chris Ramsdale

unread,
Jun 23, 2010, 12:42:05 PM6/23/10
to google-we...@googlegroups.com

Chris Ramsdale

unread,
Jun 23, 2010, 12:46:50 PM6/23/10
to google-we...@googlegroups.com
Just trying to get some scope around this issue. How many developers are still on 1.7.x (or prior) and experiencing this problem? Basically, would a 2.0.4 fix a majority (if not all) of the current issues? If not, how feasible would it be to have you upgrade to 2.0.4 from a 1.x release to fix this?

Thanks for the feedback...

-- Chris

alexl

unread,
Jun 29, 2010, 8:46:02 PM6/29/10
to Google Web Toolkit
hi, what is the svn command to download 2.0.3 source? thanks
Reply all
Reply to author
Forward
0 new messages