Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

java.lang.VerifyError Incompatible object argument for function call

Tags:

java

exception

While writing some java code I run across an Exception that I did not recognise, the java.lang.VerifyError. Some googling indicated that this is often an jvm/javac bug and I'm curious if my case is.

The lines I suspect are

private Pair<Integer/*used size*/,Pair<K,V[]>[]>[] map=(Pair<Integer,Pair<K,V[]>[]>[])Array.newInstance(Pair.class,63);//good start number

and

map[b]=new Pair<Integer,Pair<K,V[]>[]>(7,(Pair<K,V[]>[])Array.newInstance(Pair.class,7));     

but I'm far from certain.

Is this a compiler bug or is my code at fault.

Those lines are workarounds for the failure of array creation for arrays of generics that I found somewhere.

Code attached.

package osm2spacebook;

import java.util.Iterator;
import java.lang.reflect.Array;
import java.util.NoSuchElementException;

public class MultiMap<K,V> implements Iterable<K>{
    private int num_keys;
    @SuppressWarnings("unchecked")
    private Pair<Integer/*used size*/,Pair<K,V[]>[]>[] map=(Pair<Integer,Pair<K,V[]>[]>[])Array.newInstance(Pair.class,63);//good start number
    @SuppressWarnings("unchecked")
    private int bucket(K key){//position in bucket
        int h=key.hashCode();
        int b=h%map.length;
        if(map[b]==null)
            map[b]=new Pair<Integer,Pair<K,V[]>[]>(7,(Pair<K,V[]>[])Array.newInstance(Pair.class,7));
        return b;
    }
    private int position(K key){//position within bucket
        int b=bucket(key);//IMPORTANT this must use the buket function to obtain this otherwise it is a race
        for(int i=0;i<map[b].v1;i++)
            if(map[b].v2[i].v1==key)
                return i;
        if(map[b].v1==map[b].v2.length)
            map[b].v2=java.util.Arrays.copyOf(map[b].v2,map[b].v1*2);
        return map[b].v1++;
    }
    public V put(K key,V value){
        Pair<K,V[]> m=map[bucket(key)].v2[position(key)];
        for(int i=0;i<m.v2.length;i++)
            if(m.v2[i]==value)
                return value;
        m.v2=java.util.Arrays.copyOf(m.v2,m.v2.length+1);
        return m.v2[m.v2.length-1]=value;
    }
    public V[] get(K key){
        V[] v=map[bucket(key)].v2[position(key)].v2;
        return java.util.Arrays.copyOf(v,v.length);
    }
    public V[] remove(K key){
        throw new UnsupportedOperationException("Not implemented"); //TODO
    }
    public V remove(K key,V value){
        throw new UnsupportedOperationException("Not implemented"); //TODO
    }
    public boolean contains(K key){
        return position(key)<map[bucket(key)].v1;
    }
    public int numKeys(){
        return num_keys;
    }
    public Iterator<K> iterator(){
        return new Iterator<K>(){
            int bucket=0;
            int position=0;
            public boolean hasNext(){
                while(bucket<map.length){
                    if(map[bucket]!=null) 
                        if(position<map[bucket].v1)
                            return true;
                        else
                            position=0;
                    bucket++;
                }
                return false;
            }
            public K next(){
                if(hasNext())//positions cursor on next element if any
                    return map[bucket].v2[position++].v1;//updates position after read
                else
                    throw new NoSuchElementException();
            }
            public void remove(){
                throw new UnsupportedOperationException("Remove not supported in multimap iterator du to ambiguity");
            }
        };
    }
}

and the Pair class this depends on

package osm2spacebook;

public class Pair<T1,T2>{
    public T1 v1;
    public T2 v2;
    public Pair(T1 t1,T2 t2){
        v1=t1;
        v2=t2;
    }
}

Full error message

Exception in thread "main" java.lang.VerifyError: (class: osm2spacebook/MultiMap, method: position signature: (Ljava/lang/Object;)I) Incompatible object argument for function call
    at osm2spacebook.SqlOutput.<init>(SqlOutput.java:64)
    at osm2spacebook.OsmImport.<init>(OsmImport.java:142)
    at osm2spacebook.OsmImport.main(OsmImport.java:280)

Line 64 of SqlOutput is the following

private MultiMap<Integer,Integer> edge_index=new MultiMap<Integer,Integer>();
like image 713
Lijat Avatar asked Mar 23 '11 20:03

Lijat


2 Answers

A VerifyError usually means that you loaded in a class file that is somehow malformed or which references another class file that has changed in a way that causes the code in another class file to no longer be valid. For example, if you compiled a class file that referenced a method in some other class, then independently modified and recompiled the second class after altering that method's signature, you'd get this sort of error.

I'd suggest doing a clean build and seeing if this issue goes away. If not, check whether you're using up-to-date JARs and source files.

like image 140
templatetypedef Avatar answered Oct 29 '22 15:10

templatetypedef


For the unfortunate soul out there who runs across this issue... I've solved it twice now, 2 different ways (probably same underlying solution). I hope this saves you from the days I spent researching and beating head on wall...

My Project: SBT 0.13 / Lift 2.5 / Scala 2.10.2

1st SOLUTION: I upgraded from SBT 0.11 / Lift 2.4 / Scala 2.9.2 to SBT 0.13 / Lift 2.5 / Scala 2.10.2. This was hell to get all the dependencies updated properly (took a day or 2), but it worked.

2nd SOLUTION: I had no more-recent version to which I could upgrade, so I found another option: running an SBT clean didn't do the trick, so I went further and renamed (effectively deleting as far as SBT knew) all intermediate/derivative object folders (just added a '.archived' to their names) in the project folder structure (to force SBT to rebuild/populate everything from scratch), ie.

  • /lib/ --> which I believe is a folder I added, so may not be applicable to you.
  • /project/target/\*.\*
  • /project/project/target/\*.\*
  • /target/\*.\*

After that, SBT re-downloaded what it needed, rebuilt the contents of those folders, and everything worked. And as mentioned earlier, I believe this would have worked the first time also. I believe the upgrade did nothing other than create a scala_2.10.2 folder to populate freshly with intermediate/compiled objects, similar to me renaming the 'target' folders.

like image 1
Mike Avatar answered Oct 29 '22 16:10

Mike