[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mat-dev] Central Build for MAT available
|
The Array.copyOf problem in build 15
is a separate problem I introduced as a result of the WeakHashMap query.
I've fixed that one, but I think the compilation stopped before we got
to the DTFJIndexBuilder compile.
I see that build 16 still has the DTFJ
problem though. Perhaps the double quotes aren't getting through? Would
javacVerbose=true
help to see what is happening?
Andrew Johnson
| From:
| "Margewitsch, Erwin" <erwin.margewitsch@xxxxxxx>
|
| To:
| Memory Analyzer Dev list <mat-dev@xxxxxxxxxxx>
|
| Date:
| 07/12/2009 16:38
|
| Subject:
| RE: [mat-dev] Central Build for MAT
available
|
| Sent by:
| mat-dev-bounces@xxxxxxxxxxx |
Andrew, thank you for your
analysis…
Unfortunately the –extdirs
“” option has not helped (see https://build.eclipse.org/hudson/view/Athena%20CBI%20%28SVN%29/job/cbi-mat-nightly/15/console)
so we will have to go for
one of the other options you mentioned.
I will follow up this matter
and also apply for build and configuration rights for all committers ;-)
Regards, Erwin
From: mat-dev-bounces@xxxxxxxxxxx
[mailto:mat-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andrew Johnson
Sent: Montag, 7. Dezember 2009 10:45
To: Memory Analyzer Dev list
Subject: Re: [mat-dev] Central Build for MAT available
Erwin, thank you for setting up the central build for MAT - this is good
news.
These are the errors
https://build.eclipse.org/hudson/view/Athena%20CBI%20%28SVN%29/job/cbi-mat-nightly/14/console
[javac] ----------
[javac] 1. ERROR in /opt/users/hudsonbuild/.hudson/jobs/cbi-mat-nightly/workspace/build/N200912041153/eclipse/plugins/org.eclipse.mat.dtfj/src/org/eclipse/mat/dtfj/DTFJHeapObjectReader.java
(at line 327)
[javac]
JavaObject jo = jvm.getObjectAtAddress(ip);
[javac]
^^^^^^^^^^^^^^^^^^
[javac] The method getObjectAtAddress(ImagePointer) is undefined
for the type JavaRuntime
[javac] 12. ERROR in /opt/users/hudsonbuild/.hudson/jobs/cbi-mat-nightly/workspace/build/N200912041153/eclipse/plugins/org.eclipse.mat.dtfj/src/org/eclipse/mat/dtfj/DTFJIndexBuilder.java
(at line 2197)
[javac]
it = run.getHeapRoots();
[javac]
^^^^^^^^^^^^
[javac] The method getHeapRoots() is undefined for the type JavaRuntime
[javac] 18. ERROR in /opt/users/hudsonbuild/.hudson/jobs/cbi-mat-nightly/workspace/build/N200912041153/eclipse/plugins/org.eclipse.mat.dtfj/src/org/eclipse/mat/dtfj/DTFJIndexBuilder.java
(at line 4469)
[javac]
i2 = clsObj.getReferences();
[javac]
^^^^^^^^^^^^^
[javac] The method getReferences() is undefined for the type JavaObject
[javac] ----------
[javac] 19. ERROR in /opt/users/hudsonbuild/.hudson/jobs/cbi-mat-nightly/workspace/build/N200912041153/eclipse/plugins/org.eclipse.mat.dtfj/src/org/eclipse/mat/dtfj/DTFJIndexBuilder.java
(at line 4479)
[javac]
i2 = jc.getReferences();
[javac]
^^^^^^^^^^^^^
[javac] The method getReferences() is undefined for the type JavaClass
I don't think the problem is incompatible changes in DTFJ between
1.3.0 and 1.3.2, but rather an incompatibility between the javac VM level
of DTFJ and the latest DTFJ. Those methods were introduced a year ago.
I've seem this sort of problem on my machine.
The MAT DTFJ adapter compiles inside of Eclipse against the com.ibm.dtfj.api
project because the Eclipse compiler finds the com.ibm.dtfj.api files first.
PDE builds can fail because the javac compiler takes files from its boot
class path and ext dirs path first. IBM VMs have a version of dtfj in the
jre/lib/ext directory. Depending on the VM age this could be back level
compared to the version required for MAT, and be missing methods such as
getObjectAtAddress.
You may be able to avoid this by compiling with
-extdirs ""
That would be best as then the VM level would not affect the compilation.
Other options are:
1. compiling
with a more recent VM
Test the VM with javap com.ibm.dtfj.java.JavaRuntime and see if getObjectAtAddress
and getHeapRoots are available
2. trying
a 64-bit VM for compiling in case the dtfj is more recent
3. replacing
the dtfj.jar in the compiler vm ext directory with a more recent one
4. replacing
the dtfj.jar with a jar file with no classes - that way the old classes
are not found and the new ones from the com.ibm.dtfj.api project are found
instead.
Andrew Johnson
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mat-dev
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
