Community
Participate
Working Groups
Code generated from the following aspect // Do nothing when setFoo is called from within eUnset void around() : call(void AClass.setFoo(..)) && withincode(void AClass+.eUnset(..)) { return; } causes recent IBM 1.4.2 JVMs to core dump. (I have a small Eclipse project where this aspect is applied to classes generated by the EMF framework from a simple one-class, two-attribute model.)
Created attachment 16444 [details] zip of Eclipse project that illustrates bug crashes IBM 1.4.2 JVMs built 6/26 works on earlier IBM 1.4.2 JVMs, and Sun JVMs doesn't crash if you build project without aspects
Can I ask what version of Eclipse, what version of AJDT and what version of EMF you are using? I've tried to recompile the code at the command line, and it doesn't fail for me. But I am using the only 1.4.2 I can get hold of, IBM 1.4.2 SR1 build date 20040926 which is more recent than yours - are you stuck with that older version or can you try something more recent? We have had a recent situation where a particular build of an IBM JVM had problems running AJDT but I don't think it was failing during compilation, it was failing much sooner than that.
I'm using Eclipse 3.0.1.1, build ID 200410121820; AJDT 1.1.12 w/ AspectJ 1.2.0; all on Windows 2000, SP4 By "it doesn't fail for me," do you mean it builds ok, or that it runs successfully? The code compiles and weaves successfully for me under, say, the IBM 20040926 JVM, but the JVM crashes while executing the resulting code. And no, thankfully I'm not stuck using the older JVM. In fact, I'd like to move to a newer version, but for the moment only the older ones (20040626 and before) seem to work.
The SMAP (for JSR45 support) in the woven class file just doesn't seem right to me and the IBM JVMs doesn't like it if it isn't right - I guess it is doing more verification than other JVMs. Here is the data: SMAP AClassImpl.java AspectJ *S AspectJ *F 1 AClassImpl.java + 2 LazyLoader.aj com/ibm/aspectfailure/LazyLoader.aj *L 1#1,0:1,1 1#2,16:101,1 The line info just doesn't look right. The two lines there say: 1#1,0:1,1 > For this woven file, starting at line 1 there are zero lines corresponding to file id#1 (AClassImpl.java) 1#2,16:101,1 > For this woven file, starting at line 1, there are 16 lines corresponding to lines 101->117 in file id#2 (LazyLoader.aj) Now, LazyLoader doesn't have 100 lines, and only a portion of the woven file should correspond to it, certainly not starting from line 1. If I modify the compiler to omit creation of the 2nd bit of line info, the resulting code runs OK on the IBM JVM. Trying to make sense of the data, it should be something like: <placeWhereAdviceInlined>#2,<lengthOfInlinedCode>:<lineInAspectWhereInlinedCodeOriginated>,1 The number '16' is correct (from the bad line we put out), and fits in field 3, it is the lineInAspectWhereInlinedCodeOriginated. I'm still working on where to get the other data from ...
I've got my inputs and outputs mixed up !!! the first line still looks incorrect, but the second line: 1#2,16:101,1 actually means: Lines 1-16 of input file 2 (LazyLoader.aj) map to lines 101-102 in the 'output' file AClassImpl.class. I now have a patched version of AJ where I can get the correct lines for the inlined advice (so I know the right lines in LazyLoader) - the trick is getting the info correct for the 'output' .class file as we have to generate a new line number table for the advice method.
Although it appears the JSR45 information is incorrect in terms of line numbers, it turns out that the JVM is blowing up because the path is supplied for the .aj file. This information causes it to fail: ---- + 2 LazyLoader.aj com/ibm/aspectfailure/LazyLoader.aj ---- This information means it works: ---- 2 LazyLoader.aj ---- This also works: ---- + 2 LazyLoader.aj LazyLoader.aj ---- The '+' variant (the number is a file identifier for use later in the SMAP) means the source name is followed by the source path. So - my short term fix for the failure is to remove the path information from the second part of the entry. We can then look at rectifying the problem with the line numbers.
remaining work on this bug scheduled for aj5m4.
*** Bug 88279 has been marked as a duplicate of this bug. ***
remaining issues in this bug moved to 1.5.1
