ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | xmlc List | September 2006 Index

    Date Index  -->     Thread Index  -->

Re: [xmlc] Re: [enhydra] java.lang.StackOverflowError (on too many 'else if' statements)


At 09:13 PM 8/30/2006, you wrote:
>At 05:07 AM 8/30/2006, you wrote:
> >Hi,
> >
> >I don't think that recursion is causing  the problem here!
> >
> >I think that problem lies in large number of 'else if' statements
> >(inside 'syncWithDocument(Node node)' method)
>
>While I agree that it is a bit unwieldy to have all the 'else if'
>statements (only a problem with many many Id's), why would that cause
>a StackOverflowError?  IMO, it's the recursion that's filling up the
>stack.  I suppose the theory could be tested by implementing that
>method with all the 'else if' statements inside a loop instead of
>using recursion.  If it still fails with the StackOverflowError, then
>you might be right.  I'm might try that tonight.
>

Ok, I changed my mind. I agree with you. I think it is the 'else if' statements. When XMLC-compiled, we get a StackOverflowError, where the stacktrace has the following repeated multiple times....

    [javac]     at com.sun.tools.javac.tree.Tree$If.accept(Tree.java:715)
    [javac]     at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:653)
    [javac]     at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:688)
    [javac]     at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:674)
    [javac]     at com.sun.tools.javac.jvm.Gen.visitIf(Gen.java:1543)


It's interesting, though. I took a closer look at XMLObjectImpl and it defines syncWithDocument(Node) like this...


    /**
* Generated function to synchronize the fields used by the access methods.
     * This syncronizes just the node and is not recursive.
     */
    abstract protected void syncWithDocument(Node node);


It specifically states it "is not recursive"! It is syncAccessMethods(), well actually the private syncAccessMethods(Node), that recursively calls syncWithDocument(Node). I removed the recursion code generation for syncWithDocument(Node) from AccessMethods, which generates the method, and everything continues to work fine (so far as I can tell). Looks like XMLC has been doing unnecessary double recursion for quite a long time! Unless I find some problem with removing this extra recursion, I'll be checking this change in. It doesn't solve the huge 'else if' statement problem, but the extra recursion seems pretty clearly unnecessary. I'm baffled as to why it was ever added???

As for the 'else if' problem do you have any opinions, backed up by actual code examples, of the best way to get around the StackOverflow error? This is definitely something we should fix. And now that I have a whole bunch of other stuff done and checked in, I can focus more attention on this issue and, hopefully, have a fix for the next release.

Jake


> > and that this is the part
> >of code (logic) that needs to get reimplemented (maybe by using some
> >generic setter methods and/or Map objects).
> >
>How do you envision this working?  Using deferred parsing, none of
>this information is known until after the document is first loaded at
>runtime.  I'm very open to suggestions, but I'm even more open to
>concrete code implementations.  The current code works for 99% of the
>cases, so I'm not about to change it on a whim.  I'm looking for the
>simplest, most elegant, and robust way of resolving this issue.
>
>
>Jake
>
> >Regards,
> >  Slobodan Vujasinovic
> >Enhydra Development Team
> >
> >
> >
> >Jacob Kjome wrote:
> >
> >> At 04:31 PM 8/29/2006, you wrote:
> >> > My html has grown further  and it has reached the limit again. It fails
> >> >to compile.
> >> >
> >> >My worry is why is the parameter stack size -xss that I specify in
> >> >enhydrahome\ant.bat is not picked up
> >> >
> >>
> >> You'd want to check with the Ant-user list to see how to best set that
> >> using ant.bat.
> >>
> >> >I mention this in xmlc.bat too.
> >>
> >> I haven't been distributing a new version of xmlc.bat for quite a
> >> while.  It would make sense, but I haven't really gotten around to
> >> it.  For now, it is not a priority, unless you want to contribute it.
> >> I think there does exist a version in the source, but I haven't
> >> modified the build to put this in a proper location in the
> >> distribution and I haven't verified how well it works.  You are
> >> welcome to look into it.
> >>
> >> >
> >> >A fix is required.
> >>
> >> I think we can do more here.  The crux of the matter is determining
> >> the best way to avoid excessive recursion.  Again, normally it isn't a
> >> problem because usually there are not so many Id's.  However, since
> >> you do have many Id's, we may as well come up with a solution.  Here's
> >> a much smaller version of the generated method....
> >>
> >>     protected void syncWithDocument(Node node) {
> >>         if (node instanceof Element) {
> >>             String id = ((Element)node).getAttribute("id");
> >>
> >>             if (id.length() == 0) {
> >>             } else if (id.equals("hello")) {
> >>                 $element_Hello =
> >> (org.enhydra.xml.xhtml.dom.HTMLSpanElement)node;
> >>             }
> >>         }
> >>
> >>         Node child = node.getFirstChild();
> >>         while (child != null) {
> >>             syncWithDocument(child);
> >>             child = child.getNextSibling();
> >>         }
> >>     }
> >>
> >> The challenge is to determine the best way to implement this without
> >> recursion.  Of course, recursion here makes the code short, sweet, and
> >> clean.  The problem is that too much recursion brings down the JVM.
> >> One possibility would be putting first block of code inside a while
> >> loop and test the next sibling nodes inside that loop and then
> >> evaluating them rather than calling syncWithDocument(Node)
> >> recursively.  That would be a pretty straightforward way, but the
> >> while loop itself would be massively large in your case.  I'm not sure
> >> it would matter, but it wouldn't look quite as pretty as the recursive
> >> version does.  Of course there may be other approaches.  That's why
> >> I'm opening this up to a discussion.
> >>
> >> I'd like to hear as many suggestions as possible; preferably fully
> >> coded solutions.  Code away!!!
> >>
> >> Jake
> >>
> >> >
> >> >-rafeeq
> >> >
> >> >
> >> >-----Original Message-----
> >> >From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> >> >Sent: Wednesday, August 16, 2006 9:27 PM
> >> >To: xmlc@xxxxxxxxxxxxx
> >> >Cc: Mohammed Rafeeq; enhydra@xxxxxxxxxxxxx
> >> >Subject: RE: [xmlc] Re: [enhydra] java.lang.StackOverflowError File
> >> >attached
> >> >
> >> >
> >> >Ok, I think I see the problem.  The java source file is just too big for
> >> >the java compiler to handle.  The source file, even with deferred
> >> >parsing, which stores zero information on how to actually build the DOM,
> >> >is 535k and 18,579 lines long!  That's a *lot* of Id's!!!
> >> >
> >> >As such, I don't think this is a matter of an XMLC bug, per-say.
> >> >Though, then thing it seems to be bombing out on is the massive if
> >> >statement in the recursive method syncWithDocument(Node node).  The
> >> >thing is, normally, this doesn't cause problems.  It's just when this
> >> >upper limit of Id's is hit.  So, I don't think it's a high priority
> >> >issue to search for a fix, but it couldn't hurt to find an optimization
> >> >here.
> >> >
> >> >I think the approach you took to solving the issue - removing the excess
> >> >Id's and taking a different approach in your presentation object - is
> >> >the proper one.
> >> >
> >> >If anyone has suggestions on improving the generated and recursive
> >> >syncWithDocument(Node node) method, I'd be glad to hear it.
> >> >
> >> >
> >> >Jake
> >> >
> >> >At 12:59 PM 8/16/2006, Jacob Kjome wrote:
> >> > >
> >> > >Glad to hear you were able to work around it.  I will try your
> >> >original file
> >> > >when I get home tonight to see if it does, indeed, still fail with
> >> >deferred
> >> > >parsing.  If it does, its definitely something that should be
> >> >investigated and
> >> > >fixed.  I just noticed that you reported this issue in the XMLC
> >> >objectweb forge
> >> > >tracker.  I was going to suggest you do that before I saw that you
> >> > >already did.
> >> > >Thanks!
> >> > >
> >> > >Jake
> >> > >
> >> > >
> >> > >Quoting Mohammed Rafeeq <mrafeeq@xxxxxxx>:
> >> > >
> >> > >> I am not sure how to check if the command line utility passes the
> >> > >> "-for-deferred-parsing" flag to XMLC.
> >> > >>
> >> > >> Now I cleaned up my html and moved all my javascript, css to
> >> >external
> >> > >> files. More over I converted
> >> > >>
> >> > >> <td id ="abc"> <input type ="text" id="xyz"></td>
> >> > >>
> >> > >> To
> >> > >>
> >> > >> <td><input type ="text" id="xyz"></td>
> >> > >>
> >> > >> And now it compiles. I changed the way my presentation object is
> >> > >> reaching each table cell element and manipulating the content.
> >> > >>
> >> > >> But I am still curious enough to know why the earlier file failed to
> >> > >> compile. If it is a bug in xmlc we can fix it .
> >> > >>
> >> > >> Thank you.
> >> > >> -rafeeq
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >> -----Original Message-----
> >> > >> From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> >> > >> Sent: Wednesday, August 16, 2006 10:07 AM
> >> > >> To: Mohammed Rafeeq
> >> > >> Cc: xmlc@xxxxxxxxxxxxx; enhydra@xxxxxxxxxxxxx
> >> > >> Subject: RE: [xmlc] Re: [enhydra] java.lang.StackOverflowError File
> >> > >> attached
> >> > >>
> >> > >> Quoting Mohammed Rafeeq <mrafeeq@xxxxxxx>:
> >> > >>
> >> > >> > The file that is failing to compile is attached.
> >> > >> >
> >> > >> > I tried using deferred parsing  by specifying
> >> > >> >
> >> > >> > C:\xmlc -for-deferred-parsing CARGO2QC.html
> >> > >> >
> >> > >> > I get the same error
> >> > >>
> >> > >> Are you sure that the command line utility you are using passes the
> >> > >> "-for-deferred-parsing" flag to XMLC to evaluate as a metadata
> >> >option?
> >> > >>
> >> > >> >
> >> > >> > I am using I am using enhydra 5.1 and xmlc.jar: 2.2.5.. I am
> >> >working
> >> > >> > on Windows xp professional. I tried downloading the latest
> >> >xmlc.jar
> >> > >> > but it did not help either. I tried downloading the latest version
> >> > >> > enhydra app
> >> > >> > server(7.x) , created a application and tried to compile this file
> >> >,
> >> > >> > it did not help either.
> >> > >> >
> >> > >> > Since this is a show stopper I am proceeding by chopping and
> >> >reducing
> >> > >> > a few content in my html file.
> >> > >> >
> >> > >>
> >> > >> Is the full content of the HTML file needed or is some of it just
> >> >mockup
> >> > >> markup that could be removed?  You can set a CSS class name to each
> >> >row
> >> > >> in the table, such as "removeMe", that is just mockup data and
> >> >provide
> >> > >> the XMLC command line option "-delete-class removeMe" or the XML...
> >> > >>
> >> > >> <domEdits>
> >> > >>         <deleteElement elementClasses="removeMe"/> </domEdits>
> >> > >>
> >> > >> > I wanted to debug by downloading the source code. But did not know
> >> >how
> >> > >>
> >> > >> > to download that particular version from sourceforge.net
> >> > >> >
> >> > >>
> >> > >> You can check out the CVS for the tag XMLC_2_2_X (where X is the
> >> >version
> >> > >> you are interested in).  I would try XMLC_2_2_10, since it is the
> >> >latest
> >> > >> and has Eclipse project files available for it.  That will make it
> >> > >> easier to get up and running.
> >> > >>  See the following page for information on checking out XMLC CVS
> >> > >> source...
> >> > >>
> >> > >> http://forge.objectweb.org/scm/?group_id=49
> >> > >>
> >> > >> If you don't currently use a CVS client, I recommend using
> >> >TortoiseCVS
> >> > >> at http://www.tortoisecvs.org/ .  It makes things easy.  Either go
> >> >for
> >> > >> the 1.8.xx versions or the 1.9.11 version.  The latest versions of
> >> >1.9,
> >> > >> including 1.9.12 through 1.9.14, seem to suffer from various
> >> >problems
> >> > >> that prevent proper usage.
> >> > >>  I hope 1.9.15 will clear things up, but it isn't out yet.
> >> > >>
> >> > >> Jake
> >> > >>
> >> > >> > Thanks,
> >> > >> > -rafeeq
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > -----Original Message-----
> >> > >> > From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> >> > >> > Sent: Tuesday, August 15, 2006 9:21 PM
> >> > >> > To: xmlc@xxxxxxxxxxxxx; enhydra@xxxxxxxxxxxxx
> >> > >> > Cc: Mohammed Rafeeq
> >> > >> > Subject: Re: [xmlc] Re: [enhydra] java.lang.StackOverflowError
> >> > >> >
> >> > >> >
> >> > >> > What version of XMLC is being used?  Can you provide the file that
> >> > >> > causes the error?  Have you tried using XMLC's deferred parsing
> >> > >> feature?
> >> > >> > I think deferred parsing would solve this issue.
> >> > >> >
> >> > >> > Jake
> >> > >> >
> >> > >> > At 03:25 AM 8/14/2006, Slobodan Vujasinovic wrote:
> >> > >> >  >Hi,
> >> > >> >  >
> >> > >> >  >I've forwarded your message to XMLC mailing list!
> >> > >> >  >Maybe someone else already had this problem with large HTML
> >> >pages!?
> >> > >> >  >
> >> > >> >  >Which Enhydra and XMLC versions are you using currently (please
> >> >post
> >> > >> > >your response on XMLC mailing list too - xmlc@xxxxxxxxxxxxx)?
> >> > >> >  >
> >> > >> >  >Regards,
> >> > >> >  >  Slobodan Vujasinovic
> >> > >> >  >Enhydra Development Team
> >> > >> >  >
> >> > >> >  >
> >> > >> >  >
> >> > >> >  >mrafeeq@xxxxxxx wrote:
> >> > >> >  >
> >> > >> >  >>Hi all
> >> > >> >  >>
> >> > >> >  >>I have a big html file ( consisting of 550 <td> cells) . when i
> >> >run
> >> > >>
> >> > >> > the xmlc  >>  >>When I run the ant task to compile my html to
> >> >.java
> >> > >> > files it throws  >an exception like below. ( i run a xmlc task)
> >> >>>
> >> > >> >  >>xmlc:
> >> > >> >  >>    [xmlc]     CARGO2QC.html --> CARGO2QC.class
> >> > >> >  >>     [xmlc] >>> parsing
> >> > >> >  >C:\xdx\svndatafinder\src\datafinder\resources\CARGO2QC.html
> >> > >> >  >>     [xmlc] >>> using DOM Factory class:
> >> > >> >  >org.enhydra.xml.xmlc.dom.lazydom.LazyHTMLDomFactory
> >> > >> >  >>     [xmlc] >>> generating code
> >> > >> >  >>     [xmlc]     creating class:
> >> > >> >  >C:\xdx\svndatafinder\classes\Generated
> >> > >> >  >Source\datafinder\presentation\CARGO2QCHTML.java
> >> > >> >  >>     [xmlc] >>> compiling code
> >> > >> >  >>     [xmlc] javac -d C:\xdx\svndatafinder\classes -encoding
> >> > >> >  >ISO-8859-1 C:\xdx\svndatafinder\classes\Generated
> >> > >> >  >Source\datafinder\presentation\CARGO2QCHTML.java
> >> > >> >  >>
> >> > >> >  >>
> >> > >> >  >>The system is out of resources.
> >> > >> >  >>Consult the following stack trace for details.
> >> > >> >  >>java.lang.StackOverflowError
> >> > >> >  >>     [xmlc] Error: compile of generated java code failed
> >> > >> >  >>     [xmlc] org.enhydra.xml.xmlc.XMLCException: compile of
> >> > >> generated
> >> > >> >  >java code failed
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> >>org.enhydra.xml.xmlc.misc.ProcessRunner.run(ProcessRunner.java:283)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> > >>
> >> >>org.enhydra.xml.xmlc.codegen.JavaCompile.compile(JavaCompile.java:145)
> >> > >> >  >>     [xmlc]     at
> >> > >> > org.enhydra.xml.xmlc.compiler.Javac.compile(Javac.java:88)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> > >> >
> >> > >>
> >> >>org.enhydra.xml.xmlc.compiler.Compiler.compileJavaSource(Compiler.java:
> >> > >> > 153)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> > >> >
> >> >>org.enhydra.xml.xmlc.compiler.Compiler.compileDocument(Compiler.java:
> >> > >> > >18
> >> > >> > 5)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> >>org.enhydra.xml.xmlc.compiler.Compiler.compile(Compiler.java:226)
> >> > >> >  >>     [xmlc]     at
> >> > >> >  >org.enhydra.xml.xmlc.commands.xmlc.XMLC.compile(XMLC.java:132)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> > >> >
> >> >>org.enhydra.xml.xmlc.commands.xmlc.XMLC.compileHandleErrors(XMLC.java
> >> > >> > >:1
> >> > >> > 42)
> >> > >> >  >>     [xmlc]     at
> >> > >> > org.enhydra.xml.xmlc.commands.xmlc.XMLC.main(XMLC.java:153)
> >> > >> >  >>     [xmlc]     at
> >> > >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> > >> >
> >> >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> >> > >> > >ja
> >> > >> > va:39)
> >> > >> >  >>     [xmlc]     at
> >> > >> >
> >> > >> >
> >> >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> >> > >> > s
> >> > >> >  >orImpl.java:25)
> >> > >> >  >>     [xmlc]     at
> >> >java.lang.reflect.Method.invoke(Method.java:324)
> >> > >> >  >>     [xmlc]     at com.lutris.ant.taskdefs.Xmlc.execute(Unknown
> >> > >> > Source)
> >> > >> >  >>     [xmlc]     at
> >> >org.apache.tools.ant.Task.perform(Task.java:317)
> >> > >> >  >>     [xmlc]     at
> >> > >> > org.apache.tools.ant.Target.execute(Target.java:309)
> >> > >> >  >>     [xmlc]     at
> >> > >> > org.apache.tools.ant.Target.performTasks(Target.java:334)
> >> > >> >  >>     [xmlc]     at
> >> > >> >  >org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> >> > >> >  >>     [xmlc]     at
> >> > >> >  >org.apache.tools.ant.Project.executeTargets(Project.java:1250)
> >> > >> >  >>     [xmlc]     at
> >> > >> org.apache.tools.ant.Main.runBuild(Main.java:610)
> >> > >> >  >>     [xmlc]     at
> >> >org.apache.tools.ant.Main.start(Main.java:196)
> >> > >> >  >>     [xmlc]     at
> >> >org.apache.tools.ant.Main.main(Main.java:235)
> >> > >> >  >>
> >> > >> >  >>
> >> > >> >  >>On researching I found out that the java stack is getting
> >> > >> overflown.
> >> > >> >  >I tried to increase the java stack size and os stack size by
> >> > >> > mentioning  >>  >>%JAVA% -Xms256M -Xmx512M -Xss1000K -Xoss5000K
> >> >-cp
> >> > >> > %CLASSPATH% .........
> >> > >> >  >>
> >> > >> >  >>in %ENHYDRA_HOME%/bin/ant.bat
> >> > >> >  >>
> >> > >> >  >>I am using jdk 1.4.2 and the operating system is windows xp
> >> > >> > professional.
> >> > >> >  >>
> >> > >> >  >>but this did not solve the problem. Any leads will be much
> >> > >> > appreciated  >>  >>I have posted this problem in this forum too
> >> >>>
> >> > >> >
> >> >>>http://forums.devx.com/showthread.php?t=155222&highlight=java.lang.S
> >> > >> > >>t
> >> > >> >  >ackOverflowError
> >> > >> >  >>
> >> > >> >  >>Thanksm
> >> > >> >  >>-Rafeeq(mrafeeq@xxxxxxx)
> >> > >> >  >>
> >> > >> >  >>
> >> > >> >  >>
> >> > >> >
> >> > >> >
> >> >>>--------------------------------------------------------------------
> >> > >> > >>--
> >> > >> > --
> >> > >> >  >>
> >> > >> >  >>
> >> > >> >  >>--
> >> > >> >  >>You receive this message as a subscriber of the
> >> > >> > enhydra@xxxxxxxxxxxxx
> >> > >> > >mailing list.
> >> > >> >  >>To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> >> > >> >  >>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> >> > >> >  >>ObjectWeb mailing lists service home page:
> >> > >> > http://www.objectweb.org/wws  >>  >>  >  >  >
> >> > >> >  >--
> >> > >> >  >You receive this message as a subscriber of the
> >> >xmlc@xxxxxxxxxxxxx
> >> > >> > >mailing list.
> >> > >> >  >To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
> >> > >> >  >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> >> > >> >  >ObjectWeb mailing lists service home page:
> >> > >> > http://www.objectweb.org/wws
> >> > >> >
> >> > >> >
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >--
> >> > >You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
> >> > >mailing list.
> >> > >To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
> >> > >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> >> > >ObjectWeb mailing lists service home page:
> >> >http://www.objectweb.org/wws
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>
> >>--
> >>You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
> >mailing list.
> >>To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
> >>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> >>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
> >>
> >>
> >
> >
> >
> >--
> >You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
> >mailing list.
> >To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
> >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> >ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
>
>--
>You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
>mailing list.
>To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws




    Date Index  -->     Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.