java.lang.VerifyError

[Ewout Van Gossum]

I'm working on a group assignment for a uni project. A friend of mine has the exact same project/run configurations. With my friend, everything works fine, but I'm getting this error:

    Exception in thread "main" java.lang.VerifyError: Bad type on operand stack in method domain.Point.add(Ldomain/Point;)Ldomain/Point; at offset 109

    at Main.main(Main.java:11)

If I disable the cofoja by removing it from the run configuration everything's fine. Any ideas what could be the problem here? I tried stripping the code and it doesn't seem to be specific to the code I've written (Point class).

[Nhat Minh Lê]

Bad bytecode being generated, it seems, but I can't say why, really,
without further information.
What is your setup: how are you compiling, and which version of Java?
Maybe you're using a recent version of Java that conflicts with the
ASM library that we use to generate bytecode.

Please set the JVM property
com.google.java.contract.dump=$DUMP_DIRECTORY to some reasonable
directory; it will produce the instrumented class files for all
contracted classes; you can then compare those with your friend's
and/or upload them somewhere so we can take a look at what went wrong.
See http://code.google.com/p/cofoja/wiki/QuickReference for details on
the options.

Nhat

> --
> You received this message because you are subscribed to the Google Groups
> "cofoja" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cofoja+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ewout Van Gossum]

Thanks for your help.

I'm using eclipse, running on JDK 7 update 17 (64-bit). In the attachment I added some screenshots in the attachment that show how I configured things in eclipse. I also included the dumps (my friends, and mine) in the attachments in a zip file.

I also mailed my TA for the course and he suggested using the OpenJDK, but I'm on a windows machine and there doesn't seem to be an install available there (http://openjdk.java.net/install/). I'm currently trying an unofficial installer that i found via stackoverflow (https://github.com/alexkasko/openjdk-unofficial-builds#openjdk-unofficial-installers-for-windows-linux-and-mac-os-x).

[Nhat Minh Lê]

Hi,

These are not the correct dumps. You should look at the class file
dumps, no the source dumps. You need to define the JVM property
com.google.java.contract.dump when running the code with the Java
Agent, not when compiling. It should dump the class files to the dump
directory. It's the -D option to the VM:
-Dcom.google.java.contract.dump=some_dir, not the -A option to the
compiler.

Also, I see that you're running another agent (nonnullcheckweaver);
can you see if the bug is reproducible without the other agent, to
narrow down possibilities?

Nhat

[Ewout Van Gossum]

Hi, just as a quick answer, I can say that the bug is reproducable without the notnullcheckweaver.

[Ewout Van Gossum]

Ok, here is the class dump (still waiting for my friend's dump). Strangely it only contains one file (the one class on the first line of my Main class)

[Ewout Van Gossum]

Here is my friend's dump. Sorry for the amount of replies.

[Nhat Minh Lê]

OK, so I took some time to look at it; was a bit more involved than I
thought, but oh well.
Please try the following build and tell me if it works for you. You
can either grab the JAR file, or if you prefer, you can apply the
patch set and build Cofoja yourself. You can grab either at the
following URL:

http://www.huoc.org/~minh/cofoja/

For the record, the bug (at least the one I fixed) was related to an
old unimplemented method in Cofoja, which is called by the ASM library
when computing stack frame maps. Cofoja has always produced faulty
stack frame maps, as far as I can tell, due to its not implementing
the method, but the JVM 1.6 did not really care, so it kinda worked.
Now, as you saw, with JDK1.7, things broke. I've put together a fix,
but it's still quite fragile---that part of ASM seems IMHO quite
fragile. If I'm right (didn't have much time to investigate, to be
honest), it's quite possible it could break again with some specific
code patterns involving interfaces, but if that's the case, there
isn't much I could do to fix it.

I also took the opportunity to bump the ASM version to the 4.x branch,
which is, according to their changelog, necessary for proper Java7
support; it does breaks compatibility with ASM 3.x, though. I also
bumped the claimed language version to Java7; it changes nothing,
except you shouldn't get the warning about mismatched annotation
processors anymore.

Anyway, tell me if it works for you. (N.B. This is a self-contracted
build of Cofoja, so it's likely to feel a bit slower than the one you
used before, since the annotation processor will be running some
pretty heavy contracts.)

Nhat

On Thu, Apr 4, 2013 at 3:36 PM, Ewout Van Gossum

[Ewout Van Gossum]

You Sir, are my new personal hero! It works nicely. Thank you for your time and effort.

Kind Regards,

Ewout Van Gossum