Stack overflow at line: 0

[markmccall]

In hosted mode I am encountering a "Stack overflow at line: 0" message
upon receiving the result of an RPC invocation. It occurs in GWT
1.3.3 and in 1.4.10 under WinXP. It does not occur in web mode.

I have followed this in debug mode and the onSuccess() method of my
callback is executed, the code in my callback completes and then the
code starts stepping into code for the rpc proxy which I do not have
the source, so I cannot tell what is happening at that point. At some
point while in the proxy code (keep in mind it has already completed
executing my onSuccess method) the Stack overflow occurs.

I have executed other RPC calls with no issue, so I am wondering if
there is something in my data structure that is returned that is
causing the issue. I have looked for recursive references but have
not yet found any.

The data structure of my that is returned is a bit complicated to post
directly in this message, but I have been able to to create a very
simple Eclipse project that creates this without fail that I can
forward on as needed.

I have found two other threads regarding this topic, but no
resolution:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/b83221800a2f9424/9355055d6acf37a0?lnk=gst&q=stack+overflow&rnum=2#9355055d6acf37a0
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/a96c00a1731afe2f/bf9c01e76c698c44?lnk=gst&q=stack+overflow&rnum=3#bf9c01e76c698c44

Help!!
Mark McCall

[Mark McCall]

In hosted mode I am encountering a "Stack overflow at line: 0" message upon receiving the result of an RPC invocation.  It occurs in GWT 1.3.3 and in 1.4.10 under WinXP.  It does not occur in web mode.

I have followed this in debug mode and the onSuccess() method of my callback is executed, the code in my callback completes and then the code starts stepping into code for the rpc proxy which I do not have the source, so I cannot tell what is happening at that point.  At some point while in the proxy code (keep in mind it has already completed executing my onSuccess method) the Stack overflow occurs.

I have executed other RPC calls with no issue, so I am wondering if there is something in my data structure that is returned that is causing the issue.  I have looked for recursive references but have not yet found any.

The data structure of my that is returned is a bit complicated to post directly in this message, but I have been able to to create a very simple Eclipse project that creates this without fail.  I am attepting to attach it to this message.  Note that Gmail will not allow me to attach a ZIP containing executable cmd files, so I renamed the compile and shell cmds to *.cmd.rename_me.

Help!!
Mark McCall

[Miguel Méndez]

Hi Mark,

If you have code that can reproduce the problem please create an issue and attach the code to it.  There were some stack overflow bugs on linux which will be included in the next RC.  However, I do not think that they impacted Windows.

FWIW, RPC in hosted mode crosses the JSNI boundary a lot during serialization and deserialization processes.  This tends to burn a lot of stack since it involves JS, JAVA and native C code.

That said, if you have code that can reproduce the problem we can look into.

Thanks,

[Ian Bambury]

It's not much help, but I can reproduce this in 1.4, too.

 

Ian

 

http://examples.roughian.com

[Mark McCall]

Miguel,

I created an issue (1438) and attached the Eclipse project directly to that issue.  For those who wish to track this here is a direct link to the issue:

http://code.google.com/p/google-web-toolkit/issues/detail?id=1438

FYI: this will become a blocker issue for us.  If the GWT team can confirm that it has no impact whatsoever on Web mode it might ease our minds a little bit.

Thanks!

[Ian Bambury]

It's something to do with your JSON. If you comment out

 

records.add(jsonRecordToGWTClientRecord(record));

 

line in jsonToRecords() then the error disappears. I haven't tracked it further tham that - got to leave you something to do :-)

 

BTW, in case you haven't discovered this yet, you have to restart hosted mode every time you change any server-side code, in Windows at least, or you don't see the changes.

 

Ian

 

http://examples.roughian.com

[Mark McCall]

Thanks Ian,

The JSON is just a way to recreate the data structure that caused this scenario to occur.  In our real application the data structure is created from an XML source.  In both cases the resulting data structure is the same.  So I don't think it's the JSON specifically, but as I alluded to in my first post I suspect it's something with the data structure itself, perhaps even the number of "levels" of nested structures.

Also, by removing that line of code, the data structure is mostly empty, not entirely, but mostly.  Once thing to consider with this data structure is there can be many nested elements.  A Record can contain simple String attributes (in a Map) or it can contain other Records.  This nesting can potentially go on indefinitely, however I do not believe I have any recursive references in this instance.  Here is a very simple visual representation (an no, I am not using Generics in my code, I only using it here for illustration):

section1 <Section>
  - record1 <Record>
    -- attr1: key1<String>, value1<String>
    -- attr2: key2<String>, value2<String>
    -- attr3: key3<String>, value3<Record>
        -- value3: <Record>
        -- etc...
  - record2: <Record>
  - record3: <Record>

Mark

[Matthieu]

Hi Mark and Miguel,

I'm adding this post to backup Mark on this issue. I have nearly the
same error as Mark pointed in this post. I got a Stackoverflow error
at line : 0 and it happens only in Hosted Mode in Web Mod it's running
fine and I don't see this error at all. Like Mark, I have a lot of
nested data structure a bit like this :

application1 <Application>
- category1 <Category>
- parameter1 <Parameter>
- value1 <Value>
- attr1: List of Value can contain other nested value
- attr2: List of Value can contain other nested value
- parameter2 <Parameter>
- value2 <Value>
- attr1: A String
- parameter3 <Parameter>
- value2 <Value>
- attr1: A Number

And so on with multiple Applications and categories. However, even if
I receive this error, it can make my GWT project running OK in hosted
mode but sometime, I will receive a null pointer exception that I
think, should not occur. I cannot post directly my project here since
I depend on libraries that I cannot post directly. I tried to create
another project that doesn't depends on this library but it's too long
to do. But, if you want it Miguel, I could send it to you by email so
will have two different projects to track this issue down.

Best regards and good luck,

Matthieu

> On 7/25/07, Ian Bambury <ianbamb...@gmail.com> wrote:
>
>
>
>
>
> > It's something to do with your JSON. If you comment out
>
> > records.add(jsonRecordToGWTClientRecord(record));
>
> > line in jsonToRecords() then the error disappears. I haven't tracked it
> > further tham that - got to leave you something to do :-)
>
> > BTW, in case you haven't discovered this yet, you have to restart hosted
> > mode every time you change any server-side code, in Windows at least, or you
> > don't see the changes.
>
> > Ian
>

> > On 25/07/07, Mark McCall <markwmcc...@gmail.com> wrote:
>
> > > Miguel,
>
> > > I created an issue (1438) and attached the Eclipse project directly to
> > > that issue. For those who wish to track this here is a direct link to the
> > > issue:
>
> > >http://code.google.com/p/google-web-toolkit/issues/detail?id=1438
>
> > > FYI: this will become a blocker issue for us. If the GWT team can
> > > confirm that it has no impact whatsoever on Web mode it might ease our minds
> > > a little bit.
>
> > > Thanks!
>

> > > On 7/25/07, Ian Bambury < ianbamb...@gmail.com> wrote:
>
> > > > It's not much help, but I can reproduce this in 1.4, too.
>
> > > > Ian
>

> > > > On 25/07/07, Miguel Méndez < mmen...@google.com > wrote:
>
> > > > > Hi Mark,
>
> > > > > If you have code that can reproduce the problem please create an
> > > > > issue and attach the code to it. There were some stack overflow bugs on
> > > > > linux which will be included in the next RC. However, I do not think that
> > > > > they impacted Windows.
>
> > > > > FWIW, RPC in hosted mode crosses the JSNI boundary a lot during
> > > > > serialization and deserialization processes. This tends to burn a lot of
> > > > > stack since it involves JS, JAVA and native C code.
>
> > > > > That said, if you have code that can reproduce the problem we can
> > > > > look into.
>
> > > > > Thanks,
>

> > > > > >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
>
> > > > > >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> > > > > > Help!!
> > > > > > Mark McCall
>
> > > > > >http://examples.roughian.com
>

> > >http://examples.roughian.com- Hide quoted text -
>
> - Show quoted text -

[Miguel Méndez]

Hi Mark and Mathieu,

I was only able to reproduce the problem in Windows hosted mode using the code provided by Mark.  FWIW, we do not get the stack overflow problem under linux hosted mode.

Based on what I have seen, I think that object that you are trying to return forces the deserialization code to cross the Java to JavaScript boundary which consumes a lot of stack.  I believe that IE is putting up the error message after it returns from the event handler which ultimately calls your onSuccess method.

I searched for the error message and it seems that other people have run into this problem outside of GWT.  I'm not sure what we could do now to alleviate the problem.  Perhaps the work on out of process hosted mode would resolve or alleviate this issue.

HTH,

[Mark McCall]

What is it about this object that forces the crossover from Java to JavaScript?  Is it the number of levels of data?  Is it the data content itself?  Can we expect this issue to come up in web mode?

Mark

[markmccall]

After re-reading my last post I realized it sounded like I was giving
you the third degree - not my intention at all. Sorry.

Mark

On Jul 25, 4:49 pm, "Mark McCall" <markwmcc...@gmail.com> wrote:
> What is it about this object that forces the crossover from Java to
> JavaScript? Is it the number of levels of data? Is it the data content
> itself? Can we expect this issue to come up in web mode?
>
> Mark
>

> On 7/25/07, Miguel Méndez <mmen...@google.com> wrote:
>
>
>
> > Hi Mark and Mathieu,
>
> > I was only able to reproduce the problem in Windows hosted mode using the
> > code provided by Mark. FWIW, we do not get the stack overflow problem under
> > linux hosted mode.
>
> > Based on what I have seen, I think that object that you are trying to
> > return forces the deserialization code to cross the Java to JavaScript
> > boundary which consumes a lot of stack. I believe that IE is putting up the
> > error message after it returns from the event handler which ultimately calls
> > your onSuccess method.
>
> > I searched for the error message and it seems that other people have run
> > into this problem outside of GWT. I'm not sure what we could do now to
> > alleviate the problem. Perhaps the work on out of process hosted mode would
> > resolve or alleviate this issue.
>
> > HTH,
>

> > > > > >http://examples.roughian.com-Hide quoted text -

[Miguel Méndez]

No problem.  This appears to only be an issue with Windows hosted mode.  In order to deserialize a single object we go from Java->JavaScript->Java.  Now start adding that up for every level and don't forget that to even get into the event call back which actually deserializes the values you have to go from JavaScript->Java.  If you trace the path in a debugger you can see that the Java stack can get fairly deep.

I would not expect the issue to come up in web mode since it is all JavaScript.  FWIW, the code that you provided works fine in linux hosted mode.

HTH,

--
Miguel

[markmccall]

Is it fair to say that we could reduce the stack if the data structure
was some how flattened out? Any idea how deep the data structure can
be before this issue crops up?

Also, this leads me to another question regarding Javascript...once we
have GWT code compiled down into Javascript and its running in a
browser in web mode, are there any rules of thumb we should try to
adhere when it comes to the stack size that a browsers JS engine can
deal with and not suffer performance issues? Specifically we expect
our user base to be primarily IE 6. Of course given that the GWT
compiler is going to do its best to optimize the javascript, I expect
any optimizations I try to apply to the Java code may not be
effective.

On Jul 25, 5:26 pm, "Miguel Méndez" <mmen...@google.com> wrote:
> No problem. This appears to only be an issue with Windows hosted mode. In
> order to deserialize a single object we go from Java->JavaScript->Java. Now
> start adding that up for every level and don't forget that to even get into
> the event call back which actually deserializes the values you have to go
> from JavaScript->Java. If you trace the path in a debugger you can see that
> the Java stack can get fairly deep.
>
> I would not expect the issue to come up in web mode since it is all
> JavaScript. FWIW, the code that you provided works fine in linux hosted
> mode.
>
> HTH,
>

> > > > > > > >http://examples.roughian.com-Hidequoted text -

[George Georgovassilis]

I've seen this error on different occasions not involving hosted mode
but IE7, caused by a wide variety of conditions from bad compiler
output to things that should have been NPEs. Anyway, if it is just a
problem of stack size and not infinite recursion why don't you try the
-Xss option on the VM that is running hosted mode?

> ...
>
> read more »

[Miguel Méndez]

Hi Mark,

Comments inline.

On 7/25/07, markmccall <markw...@gmail.com> wrote:

Is it fair to say that we could reduce the stack if the data structure
was some how flattened out?  Any idea how deep the data structure can
be before this issue crops up?

I would expect that flattening the data structure would help.  I do not have a sense for how deep the structure can be before this happens.  It is unfortunate that you would have to change the structure of your code to work around a hosted mode only issue.  That said it would be good to see what the threshold is or in the larger sense what changes cause the problem to go away.  It does bother me that we do not know *exactly* why this happens on IE.

Also, this leads me to another question regarding Javascript...once we
have GWT code compiled down into Javascript  and its running in a
browser in web mode, are there any rules of thumb we should try to
adhere when it comes to the stack size that a browsers JS engine can
deal with and not suffer performance issues?  Specifically we expect
our user base to be primarily IE 6.  Of course given that the GWT
compiler is going to do its best to optimize the javascript, I expect
any optimizations I try to apply to the Java code may not be
effective.

I would avoid deeply recursive algorithms where possible.  Other than that, I would rely on the compiler's optimizations.

On Jul 25, 5:26 pm, "Miguel Méndez" < mmen...@google.com> wrote:
> No problem.  This appears to only be an issue with Windows hosted mode.  In
> order to deserialize a single object we go from Java->JavaScript->Java.  Now
> start adding that up for every level and don't forget that to even get into
> the event call back which actually deserializes the values you have to go
> from JavaScript->Java.  If you trace the path in a debugger you can see that
> the Java stack can get fairly deep.
>
> I would not expect the issue to come up in web mode since it is all
> JavaScript.  FWIW, the code that you provided works fine in linux hosted
> mode.

Cheers,

[Duc]

Hi all,

I'm seeing the same "Stack overflow at line: 0" behavior when sending
an object graph back (essentially a nested data structure) where a
type of object can be nested to n levels. What I'm seeing (for our
specific case) is when the object is nested more than 4 levels, the
"Stack overflow at line: 0" warning always occurs in hosted mode (of
course, never in web mode). For example (we define our data structure
using xml and use XStream to unmarshall and send back the object graph
to the client):

<module ...
<layouts...
<layout...
<layout...>
<layout>
<layout.../>
</layout>
<layout>
</layouts>
<module>

The layouts can be nested and are of the same object type. I was going
to submit a bug/enhancement report for this since I can repeat it
every single time. I'm pretty sure it's all related to n-level of a
nested data structure, since the service method is only returning this
object graph.

We're been living with this for about 4 months now but if this can be
identified & fixed (since it's only a development annoyance), that
would make a lot of people feel better.

Miguel, I can create a project and submit a bug/issue if you want to
spend more time on it :-)

Thanks,
-Duc

On Jul 26, 10:00 am, "Miguel Méndez" <mmen...@google.com> wrote:
> Hi Mark,
>
> Comments inline.
>

[markmccall]

Hi Miguel,

Have you had a chance to look at this issue any further? I have not
seen any more updates in the Issue Tracker.

Like you, I do not have a sense for how deep the data structure can be
before this issue crops up. I would _consider_ flattening my
structure as an absolute last resort, but in my scenario, the data
structure does not have static number of levels and is quite dynamic,
so while I may be able to avoid the issue for a few known cases, there
is not much I can do in the long term.

Thanks,
Mark

On Jul 26, 10:00 am, "Miguel Méndez" <mmen...@google.com> wrote:

> Hi Mark,
>
> Comments inline.

[Miguel Méndez]

Hi Mark,

I have not had a chance to get back to this.  This seems to be triggered by a known issue with IE.  It is still a somewhat of a research project to figure out how to work around it.

I'll take a look at it as soon as I get a chance.

Thanks,