| Summary: | SIOOBE seen on STS | ||
|---|---|---|---|
| Product: | [Tools] AspectJ | Reporter: | Andrew Clement <aclement> |
| Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | andrew.eisenberg, mi_th |
| Version: | 1.6.10 | ||
| Target Milestone: | 1.6.11 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Andrew Clement
Some of that code was using handle chars directly rather than through the Handle Delimiter class - so when those have changed this code won't have seen the change. However, I can't see why immediately why the recent handle changes would have contributed to the SIOOBE. So, as well as the change I've added a guard try/catch which will display the handle in question (and carry on running) - if the user can recreate we can look at the problematic handle then. latest ajdt contains the changes *** Bug 330322 has been marked as a duplicate of this bug. *** Seem to have finally gotten to the bottom of this. The debug I added triggered this:
Handle processing problem, the handle is: =petclinic/src\/main\/java<com.springsource.petclinic.
web*PetController_Roo_Controller.aj'PetController_Roo_Controller)PetController.findPetsByOwnerForm)QModel;
java.lang.StringIndexOutOfBoundsException: String index out of range: -28
at java.lang.String.substring(String.java:1938)
at org.aspectj.asm.AsmManager.getTypeNameFromHandle(AsmManager.java:643)
at org.aspectj.asm.AsmManager.removeRelationshipsTargettingThisType(AsmManager.java:705)
at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1020)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:514)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:447)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:432)
at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98)
at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652)
at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1021)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:305)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:185)
at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:127)
at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:91)
at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:257)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
when adding a field to a 'Pet' class in Roo petclinic.
The ';' is the key. ';' is used in some handles like the one above around arg types, but it is also used internally to AJ for 'phantom' handles - handles that don't point to real things (like types that don't come from source but came in from a jar or elsewhere). The code that blows up is only ever expecting to be used to handle phantom handles - so when called because the handle has a ';' at the end, it fails.
should say what the fix is. Well when recognizing a phantom handle, we not only look for the ';' but also at the preceeding character, which, for a phantom handle, is always '/' *** Bug 333107 has been marked as a duplicate of this bug. *** |