Community
Participate
Working Groups
Doing bytecode weaving of a large application - get an out of memory error regardless of the max stack size. But if it is protected with a particular aspect, the weaving succeeds with a 512MB maximum stack size. The aspect that enables the protection to complete prints various warning messages.
The weaving fails for various combinations of other aspects and only works when the aspect below is woven: import javax.servlet.http.HttpServletRequest; import javax.servlet.http.Cookie; import javax.servlet.ServletRequest; import java.sql.Statement; import java.sql.ResultSet; import java.lang.Runtime; import java.lang.System; aspect Protect_WeaveReport { declare warning: call (public String[] ServletRequest+.getParameterValues(String)): "getParameterValues called"; declare warning: call (public String ServletRequest+.getParameter(String)): "getParameter called"; declare warning: call(public void *.printStackTrace(..)): "printStackTrace called"; declare warning: call (public void *.addCookie(Cookie)): "addCookie called"; declare warning: call (public Cookie[] *.getCookies()): "getCookies called"; declare warning: call (public ResultSet Statement.executeQuery(String)): "executeQuery called"; declare warning: call (public int Statement.executeUpdate(String)) || call (public int Statement.executeUpdate(String, ..)): "executeUpdate called"; declare warning: call (public * Runtime.exec(String, ..)) || call (public * Runtime.exec(String[], ..)): "exec called"; declare warning: call (public String System.setProperty(String, String)): "setProperty called"; declare warning: call (public * System.load(String)) || call (public * System.loadLibrary(String)) || call (public * Runtime.load(String)) || call (public * Runtime.loadLibrary(String)): "load or loadLibrary called"; }
Created attachment 33657 [details] ajcore file
Am running the weaving programatically - using the bareMain entry point.
An interesting exception is captured in the ajcore file: java.lang.NullPointerException at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.handleInternalException(Compiler.java:389) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.ajc$privMethod$org_aspectj_ajdt_internal_compiler_CompilerAdapter$org_aspectj_org_eclipse_jdt_internal_compiler_Compiler$handleInternalException(Compiler.java:1) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$afterReturning$org_aspectj_ajdt_internal_compiler_CompilerAdapter$2$f9cc9ca0(CompilerAdapter.aj:74) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:367) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:811) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:230) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:156) at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:112) at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60) at org.aspectj.tools.ajc.Main.run(Main.java:326) at org.aspectj.tools.ajc.Main.runMain(Main.java:240) at org.aspectj.tools.ajc.Main.bareMain(Main.java:111) at com.unisys.security.protect.Protect.protectJAR(Protect.java:858) at com.unisys.security.protect.Protect.protectEAR(Protect.java:746) at com.unisys.security.protect.Protect.access$6(Protect.java:701) at com.unisys.security.protect.Protect$ProtectThread.run(Protect.java:187) if this were only triggered when the aspect was included - that explains why it goes OOM when the aspect isnt there. When the exception occurs I guess we crash before we can get OOM. The problem is that blowing up when handling the exception is causing us to fail to see the original exception that is occurring. I half wonder if its related to the use of the bareMain entrypoint. Are you supplying non-null parameters for all the parameters to bareMain?
are you still having problems with this?
memory usage was drastically reduced in 1.5.1a - which will hopefully help this case. please reopen if you still have a problem.
