Recent changes to patches

fix for compilation error of runtime plugin in CVS

Rafal Krzewski — Thu, 05 Oct 2006 22:26:14 -0000

net.sf.coverlipse.runtime.init.SerializedMethodUtil
compilation fails due to unresolved
org.eclipse.core.resources.IFile import.

Solution - add org.eclipse.core.resources plugin to
the dependencies. Patch does just that.

fix for trailing NOP instrumetiation problem

Rafal Krzewski — Thu, 05 Oct 2006 22:19:19 -0000

I am using Coverlipse to monitor tests coverage in an
AspectJ enabled project (with quite promising results).
I encountered a problem with
BasicBlockIdentifier.insertBlockDelimiters method
bailing out on an AspectJ modified method. The method
has a NOP instruction at the very end, after the return
instruction:

0 aload_0
1 invokestatic #81
<net/java/dev/tap/WorkingCopy.ajc$perObjectBind>
4 aload_0
5 invokestatic #77
<net/java/dev/tap/WorkingCopy.hasAspect>
8 ifeq 25 (+17)
11 aload_0
12 aload_0
13 invokestatic #65 <net/java/dev/tap/WorkingCopy.aspectOf>
16 aload_0
17 aconst_null
18 invokestatic #69
<net/java/dev/tap/TestObject.getState_aroundBody1$advice>
21 checkcast #71 <java/lang/String>
24 areturn
25 aload_0
26 invokestatic #73
<net/java/dev/tap/TestObject.getState_aroundBody0>
29 areturn
30 nop

Instrumenting this method fails with:

net.sf.coverlipse.runtime.recording.CoverlipseRecordingException:
NullPointerException when trying to insert block
delimiters to method getState in class
net.java.dev.tap.TestObject
at
net.sf.coverlipse.runtime.recording.ByteCodeModifyer.weaveCallbacksToMethod(ByteCodeModifyer.java:103)
at
net.sf.coverlipse.runtime.recording.ByteCodeModifyer.weaveCallbacks(ByteCodeModifyer.java:70)
at
net.sf.coverlipse.runtime.junit.CoverageClassLoader.modifyClass(CoverageClassLoader.java:53)
at
de.uka.ipd.coverage.org.apache.bcel.util.ClassLoader.loadClass(ClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at
net.java.dev.tap.ConcurrencyTest$1.runInternal(ConcurrencyTest.java:10)
at
net.java.dev.tap.util.CoordinatedRunnable.run(CoordinatedRunnable.java:36)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
at
net.sf.coverlipse.runtime.recording.BasicBlockIdentifyer.insertBlockDelimiters(BasicBlockIdentifyer.java:226)
at
net.sf.coverlipse.runtime.recording.ByteCodeModifyer.weaveCallbacksToMethod(ByteCodeModifyer.java:100)
... 10 more

I managed to get around this problem by inserting a
simple null-check in the instruction iteration loop,
which allowed me to move along with my tests. I am not
sure if this is the correct way of putting delimiters
near this weird NOP, but I suspect that it does not
matter much because it is unreachable anyway.

Contact me (rafal at caltha.pl) if you would like to
set up a test workspace with TAP - the toy project I
use Coverlipse on.

fix for URL-encoded paths issue

Rafal Krzewski — Wed, 04 Oct 2006 21:09:38 -0000

I am running Eclipse on MS Windows XP. When I first
attempted to use Coverlipse on project, clicking on
classes in in the Coverage view did nothing - the
editors would not open or get focus. My investigation
showed that the File object embedded in
ClassFileLocation contains the path that is
URL-encoded, along the lines of
C:\Documents%20and%20Settings\rafal\My%20Documents\...

I must admit that I did not dig into the cause _why_
those paths are enconded this way. I just decoded the
path using java.net.URLDecoder and used Coverlipse
happily everafter. The attached patch does this trick.

fix for failed coverage evaluation for a synthetic method

Rafal Krzewski — Wed, 04 Oct 2006 20:35:13 -0000

Here's what happens when Coverlipse tries to evaluate
coverage for a synthetic glue method that was injected
by AspectJ:

java.lang.NullPointerException
at
de.uka.ipd.coverage.natures.BlockCoverageNature.evaluateCompleteCoverage(BlockCoverageNature.java:67)
at
de.uka.ipd.coverage.natures.TestedClassEvaluation.call(TestedClassEvaluation.java:33)
at
de.uka.ipd.coverage.natures.TestedClassEvaluation.run(TestedClassEvaluation.java:50)

The method does not have a LineNumberTable, which is
fine because it is not compiled from source. The
attached part skips the evaluation for that method.
This is correct behaviour because the goal is checking
coverage of the sources (including AJ advice bodies)
and not the glue methods that are injected at bytecode
level.

fix for an exception on instrumentiation attempt

Rafal Krzewski — Tue, 03 Oct 2006 21:45:07 -0000

Coverlipse is attempting to instrument a class that is
loaded from a jar - .class file for it is not available
in the workspace. This causes the following exception
to be thrown:

java.lang.IllegalArgumentException: cannot find a
resource for org\aspectj\lang\NoAspectBoundException.class
at
net.sf.coverlipse.runtime.recording.RuntimeClassFileLocator.createFileFromRelativeLocation(RuntimeClassFileLocator.java:75)
at
net.sf.coverlipse.runtime.recording.RuntimeClassFileLocator.createFileFor(RuntimeClassFileLocator.java:67)
at
net.sf.coverlipse.runtime.recording.RuntimeClassFileLocator.<init>(RuntimeClassFileLocator.java:34)
at
net.sf.coverlipse.runtime.junit.CoverageClassLoader.modifyClass(CoverageClassLoader.java:52)
at
de.uka.ipd.coverage.org.apache.bcel.util.ClassLoader.loadClass(ClassLoader.java:160)

I was able to work around this issue by replacing the
throw in createFileFromRelativeLocation by a return
null statement. This allows the instrumentiation to
proceed. Of course coverage infromation for the class
from the jar is not available, but I am not intersested
in it anyway.

fix for thread safety issue in BCEL

Rafal Krzewski — Tue, 03 Oct 2006 20:27:19 -0000

While running tests that involved multiple threads I
was getting a score of weird exceptions from Coverlipse
saying that my methods had strange truncated
signatures. Upon closer examination it turned out that
BCEL Util and Type classes are not thread safe. Each
one of them uses private static int consumed_chars;
field that is used internally by a few methods. What
shortsightedness...

The attached patch fixes the problem by putting
synchronized keyword on each of the methods accessing
those fields. The methods are themselves static so
synchronized keyword provides a class wide lock thus
effectively protecting the fields.

This isssue should be reported upstream to BCEL if it
is still being develpoped. Otherwise we'll have to
reapply the fix each time BCEL sources are upgraded
within Coverlipse repository.

testcase and fix for bug 1230280 (generics support)

Rafal Krzewski — Mon, 11 Jul 2005 12:46:58 -0000

a test case for
http://sourceforge.net/tracker/index.php?func=detail&aid=1230280&group_id=139107&atid=743505