Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#958 closed defect (fixed)

ClassFormatError with custom build that has a large profile

Reported by: James Burke Owned by: jkuhnert
Priority: high Milestone:
Component: General Version: 0.4
Keywords: Cc: jkuhnert@…, scott@…
Blocked By: Blocking:

Description

Using the attached classformatexception.profile.js (from Jason Cline), it is possible to generate the following exception during the Rhino compression step:

Exception in thread "main" java.lang.ClassFormatError?: Invalid method Code length 66176 in class file org/mozilla/javascript/gen/c1

at java.lang.ClassLoader?.defineClass1(Native Method) at java.lang.ClassLoader?.defineClass(ClassLoader?.java:620) at java.lang.ClassLoader?.defineClass(ClassLoader?.java:465) at org.mozilla.javascript.DefiningClassLoader?.defineClass(DefiningClassLoader?.java:57) at org.mozilla.javascript.optimizer.Codegen.defineClass(Codegen.java:122) at org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:77) at org.mozilla.javascript.Context.compileImpl(Context.java:2265) at org.mozilla.javascript.Context.compileString(Context.java:1314) at org.mozilla.javascript.Context.compileString(Context.java:1303) at org.mozilla.javascript.tools.shell.Main.loadScriptFromSource(Main.java:487) at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:403) at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:369) at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:360) at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:153) at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:83) at org.mozilla.javascript.Context.call(Context.java:528) at org.mozilla.javascript.ContextFactory?.call(ContextFactory?.java:447) at org.mozilla.javascript.tools.shell.Main.exec(Main.java:136) at org.mozilla.javascript.tools.shell.Main.main(Main.java:114)

Attachments (2)

classformatexception.profile.js (739 bytes) - added by James Burke 13 years ago.
profile that can cause the exception
new.classformatexception.profile.js (1.0 KB) - added by scott@… 13 years ago.

Download all attachments as: .zip

Change History (18)

Changed 13 years ago by James Burke

profile that can cause the exception

comment:1 Changed 13 years ago by jkuhnert@…

Can anyone get this to consistently create errors on their machine? I can't get it to bomb out at all on mine. I have a few ideas on possible solutions but would need a guinea pig (or to decipher the right jre mixture to produce the errors) to try them on.

comment:2 Changed 13 years ago by James Burke

I was able to reproduce with the attached profile. I can try things if you want. I tried using jvmarg for the min/max memory (used 64 and 128 respectively) for the <java> task that is used to launch the rhino jar to do the compression, but that didn't help.

comment:3 Changed 13 years ago by jkuhnert@…

Cc: jkuhnert@… added

Sorry I didn't reply earlier. (no email notifies go out for me here)

Sounds great! Yeah I don't think it's a memory issue (maybe) but you could try two things (just as an exercise in finding out what/why )

1) In the dojo/buildscripts/build.xml file, replace the "-rhino-compress" task with this and see what happens:

<target name="-rhino-compress"

unless="nostrip"> <copy overwrite="true" file="${srcFile}" tofile="${dstFile}.uncompressed.js" /> <java jar="./lib/custom_rhino.jar" fork="true" output="${dstFile}">

<arg value="-opt -1" /> <arg value="-c" /> <arg value="${srcFile}" />

</java>

</target>

2) ~Only~ for the sake of understanding why, modify the un-built version of dojo.js such that it doesn't wrap itself with if (typeof dojo == "undefined" ) {

}... Ie just take that if out even if it's not correct for real usage.

If neither option 1 or 2 work I feel pretty comfy with rhino now, so maybe we could knock out this issue and the other one hanging around in trac if it ~has~ to be done...

comment:4 Changed 13 years ago by James Burke

Hmm. I just updated to r4402 (the latest on the trunk around this moment), and I tried to reproduce the error with the attached profile file, but it didn't fail this time. Odd. Don't have enough time at the moment to figure out why. I am on OSX 10.4 using Java 1.5.

comment:5 Changed 13 years ago by dylan

Resolution: fixed
Status: newclosed

Jason Cline confirms that it is no longer an issue for him either, so resolving as fixed.

comment:6 Changed 13 years ago by scott@…

Resolution: fixed
Status: closedreopened
Version: 0.20.4

I just got the latest code from Subversion and am seeing this issue. I'll paste the stack trace below and the post my custom build profile.

Exception in thread "main" java.lang.ClassFormatError?: Invalid method Code length 66455 in class file org/mozilla/javascript/gen/c1

at java.lang.ClassLoader?.defineClass1(Native Method) at java.lang.ClassLoader?.defineClass(ClassLoader?.java:620) at java.lang.ClassLoader?.defineClass(ClassLoader?.java:465) at org.mozilla.javascript.DefiningClassLoader?.defineClass(DefiningClassLoader?.java:57) at org.mozilla.javascript.optimizer.Codegen.defineClass(Codegen.java:122) at org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:77) at org.mozilla.javascript.Context.compileImpl(Context.java:2265) at org.mozilla.javascript.Context.compileString(Context.java:1314) at org.mozilla.javascript.Context.compileString(Context.java:1303) at org.mozilla.javascript.tools.shell.Main.loadScriptFromSource(Main.java:487) at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:403) at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:369) at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:360) at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:153) at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:83) at org.mozilla.javascript.Context.call(Context.java:528) at org.mozilla.javascript.ContextFactory?.call(ContextFactory?.java:447) at org.mozilla.javascript.tools.shell.Main.exec(Main.java:136) at org.mozilla.javascript.tools.shell.Main.main(Main.java:114)

Changed 13 years ago by scott@…

comment:7 Changed 13 years ago by jkuhnert

Scott, have you tried doing a build with the "-opt -1" suggestion I had posted previously?

comment:8 Changed 13 years ago by guest

Cc: scott@… added

I changed the code from:

<target name="-rhino-compress"
  unless="nostrip">
  <copy overwrite="true" file="${srcFile}" tofile="${dstFile}.uncompressed.js" />
  <java jar="./lib/custom_rhino.jar" fork="true" output="${dstFile}">
    <arg value="-c" />
    <arg value="${srcFile}" />
  </java>
</target>

to:

<target name="-rhino-compress"
  unless="nostrip">
  <copy overwrite="true" file="${srcFile}" tofile="${dstFile}.uncompressed.js" />
  <java jar="./lib/custom_rhino.jar" fork="true" output="${dstFile}">
    <arg value="-opt -1" />
    <arg value="-c" />
    <arg value="${srcFile}" />
  </java>
</target>

and got the following error:

Didn't understand "-opt -1". 
Valid arguments are:
    -w
    -version 100|110|120|130|140|150
    -opt [-1|0-9]
    -f script-filename
    -e script-source

comment:9 Changed 13 years ago by jkuhnert

Owner: changed from anonymous to jkuhnert
Status: reopenednew

Ah..Sorry about that...

Try this out instead, http://blog.dojotoolkit.org/2005/09/14/compressing-huge-js-files.

Let me know if it works and maybe we can modify the main buildscript to always use it.

comment:10 Changed 13 years ago by scott@…

Yep, doing it via command line with the "-opt -1" did the trick. I created a batch file that fires off the regular ant build and then calls the following:

java -Xmn100M -Xms500M -Xmx500M -jar "PATH_TO_DOJOlibcustom_rhino.jar" -opt -1 -c "PATH_TO_DOJO
eleasedojodojo.js.uncompressed.js" > "PATH_TO_DOJO
eleasedojodojo.js"

However, I'm sure that others would appreiciate it if this were included in the regular ANT build. Regardless, thanks for your help!

comment:11 Changed 13 years ago by jkuhnert

Great!

If you could humor me, since you currently get a consistent failure when it's not setup properly...What happens if you take out all of the -X options but leave the -opt -1 ? I'm hoping that the -1 option means it won't try to compile any classes at all, taking away the need to increase memory.

comment:12 Changed 13 years ago by scott@…

You are correct. I removed the memory settings (-Xmn100M -Xms500M -Xmx500M) and it worked perfectly. For the reference of others, here is the new line I'll be using in my batch file:

java -jar custom_rhino.jar -opt -1 -c "C:@spiderDojo
eleasedojodojo.js.uncompressed.js" > "C:@spiderDojo
eleasedojodojo.js"

comment:13 Changed 13 years ago by scott@…

... or for those of you not developing on my box :)

java -jar "PATH_TO_DOJOuildscriptslibcustom_rhino.jar" -opt -1 -c "PATH_TO_DOJO
eleasedojodojo.js.uncompressed.js" > "PATH_TO_DOJO
eleasedojodojo.js"

comment:14 Changed 13 years ago by jkuhnert

Resolution: fixed
Status: newclosed

Great! Thanks a ton for testing this out so much Scott. I've made a permanent change to fix this in the core dojo build.xml file, so hopefully you'll be the last victim of this piece of logic.

comment:15 Changed 13 years ago by scott@…

And thank you for the terrific turnaround time on this!

I just updated to the latest from Subversion and the build process works perfectly without the batch file / command line workaround.

comment:16 Changed 12 years ago by (none)

Milestone: 0.4

Milestone 0.4 deleted

Note: See TracTickets for help on using tickets.