Re: [aspectj-users] AspectJ 1.5.3: java.lang.NullPointerException at org

["Andy Clement" <andrew.clement@xxxxxxxxx>]

Hi,

> debug weaving 'uy.com.netlabs.dsmpp.output.fragmentation.SMPPFragmentationStrategy'
> abort trouble in:
> uy.com.netlabs.dsmpp.output.fragmentation.SMPPFragmentationStrategy --
> (NullPointerException) null
> null
> java.lang.NullPointerException
>       at org.aspectj.apache.bcel.generic.MethodGen.<init>(MethodGen.java:305)
>        at org.aspectj.weaver.bcel.LazyMethodGen.initialize(LazyMethodGen.java:295)
>        at org.aspectj.weaver.bcel.LazyMethodGen.markAsChanged(LazyMethodGen.java:502)

I've had this kind of error reported to me via various routes but am
never able to get enough diagnostics to progress it - I dont want to
simply guard the NPE as it means something is happening that is
completely unexpected.  Yours is the first exception trace that has
actually included a line number - too many previous reporters have
been running on JVMs/JITs that lose such vital diagnostic information.

> From what I can tell this occurs when we encounter bytecode that isn't
quite as well formed as we'd like.  It is well formed enough to verify
and execute fine, but not quite well formed enough for us to weave it.
For example, here is some peculiar code:

public void m();
 Code:
  Stack=2, Locals=3, Args_size=1
  0:   iconst_5
  1:   istore_1
  2:   ldc     #2; //String hello world
  4:   astore_2
  5:   getstatic       #3; //Field java/lang/System.out:Ljava/io/PrintStream;
  8:   aload_2
  9:   invokevirtual   #4; //Method
java/io/PrintStream.println:(Ljava/lang/String;)V
  12:  iload_1
  13:  iconst_5
  14:  iadd
  15:  istore_1
  16:  return
 LineNumberTable:
  line 3: 0
  line 4: 2
  line 5: 7
  line 6: 12
  line 7: 16

What's wrong with it?  Well the problem is that in the line number
table, line 5 points to position 7 - and that's not right, it should
point to either 5 or 8, but not halfway through an instruction.  A
compiler should ideally never output code containing this kind of
inconsistency but they can sometimes - see bugzilla entry 155763 for
example.

What exact compiler version was used to build the code that is input
to the weaving process? (not the JVM level used for LTW).  I really
need to see what is inconsistent in the bytecode to resolve this
problem.

> java.lang.VerifyError: Unable to pop operan when not using -XnoInline
Are you writing annotation style aspects or code style aspects?