Summary: | java.lang.InternalError: name is too long to represent | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Erik G <erik> |
Component: | Jasper | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | olivier_thomann, rschwager, taras.tielkes |
Priority: | P2 | Keywords: | JDK1.5 |
Version: | 5.5.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Attachments: | Large JSP compiled by jdt |
Description
Erik G
2006-03-23 21:48:03 UTC
First, note that Tomcat already supports the classdebuginfo (true by default, can be set to false) option to be passed into the compiler at runtime: maybe try using that? (See http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html#Configuration for documentation) Second, as you noted, this is a combination of a JDK and/or Eclipse JDT bugs, not a Tomcat bug per-se. I hesitate to put in place any temporary workaround as a band-aid, and then remove it later when the vendor has fixed their root problem. Instead, you may want to bring this up in the relevant Eclipse forum and/or bug tracking system. Thanks. The specific JVM bug that is occuring is already noted at Sun (anyone reading this, please vote for Sun to fix the bug - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6294277). I've also posted a bug to Eclipse's bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=136752 I would suggest adding some information to Tomcat's docs because Tomcat's default configuration is to use debug mode and the JDT compiler. The bug will occur without the end-user being aware that the root cause is the use of JDT and the error from the JVM is very cryptic. The only resolution is either to find this bug or hunt-and-peck through the config settings to fix. Also, I'm not a JDT expert, but it might be worthwhile looking into if the extra debug information being included by JDT can be turned off by Tomcat on compilation. From what I understand, the field in question is not for use by java-debuggers but for non-java compilers. I'm reopening this because it looks like JDT does not put in a SourceDebugExtension during compilation. Looking at the Jasper source code, there are references to the SourceDebugExtension and JSR-045 in the SmapUtils.class. I'm not sure how this is used or under what circumstances. I am going to try rerunning the test cases today using javac inside the container instead of jdt. I will post the results here and the the Eclipse bug as well. The SmapUtils.class can be seen here: http://svn.apache.org/viewcvs.cgi/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/SmapUtil.java?view=markup The JDT bug I opened can be found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=136752 If you want a change to Tomcat's docs, please let us know what text you'd like us to use, and we'll gladly add it to the docs. But please don't reopen just for the sake of reopening it, because it's a JDT and/or Sun bug, not a Tomcat bug, as already noted above. (In reply to comment #4) I didn't reopen this for the sake of re-opening it nor for the documentation fix... JDT *does not* add the JSR-045 SourceDebugExtension - Jasper seems to. Please see comment #3 that I added when I reopened this bug - the SourceDebugExtension code is in Tomcat's SVN repository (see the link in #4). The Sun JVM issue is really a spec documentation conflict. The overall JVM specs quite clearly says there is a 4K limit for attributes, the JSR spec says something different. I would think the JVM spec is much more important here. For large JSPs, Jasper is adding > 4K work of SourceDebugExtension information to the compiled classes - this violates the JVM spec and causes the bug. As I said in my comment, I don't know how the SmapUtil and related classes are being used by Jasper or when they are used. According to the analysis from the JDT developer looking at this issue on their end: "In the .class file that I got, there is such an attribute at the end. Attribute: SourceDebugExtension Length: 81342." Since JDT does not add the SourceDebugExtension attribute during compilation, it would appear that Jasper is adding it to the bytecode after compilation? I'm open to an alternate explanation... I'm attaching the .class and .java files to this bug so you can look at them too. In my opinion, this should be re-opened and looked into, but I will defer to you. Created attachment 18132 [details]
Large JSP compiled by jdt
here's the file that was sent to the JDT for analysis. As they logged in their
Bugzilla, JDT doesn't add the attribute in question during compilation but you
can see it in the .class file at the end.
OK, now I understand why you re-opened it. Thanks for the explanation. I'll look into it when I get a chance, hopefully someone else will get a chance sooner ;) (In reply to comment #5) > The Sun JVM issue is really a spec documentation conflict. The overall JVM specs > quite clearly says there is a 4K limit for attributes, the JSR spec says > something different. I would think the JVM spec is much more important here. > > For large JSPs, Jasper is adding > 4K work of SourceDebugExtension information > to the compiled classes - this violates the JVM spec and causes the bug. Erik, Where did you get that information about the 4K limit. An attribute length can be on 4 unsigned byte. I have added a known issues section to the Jasper/JSP how-to that explains this issue and gives some options on how to work around it. |