it-swarm-tr.com

Java.lang.VerifyError alma nedenleri

Aşağıdaki Java.lang.VerifyError dosyasını araştırıyorum

Java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMonthData signature: (IILjava/util/Collection;Ljava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/Apache/struts/util/MessageRe˜̴Mt̴MÚw€mçw€mp:”MŒŒ
                at Java.lang.Class.getDeclaredConstructors0(Native Method)
                at Java.lang.Class.privateGetDeclaredConstructors(Class.Java:2357)
                at Java.lang.Class.getConstructor0(Class.Java:2671)

Sunucu uygulamasının konuşlandırıldığı jboss sunucusu başlatıldığında oluşur . jdk-1.5.0_11 ile derlenir ve başarılı olmadan jdk-1.5.0_15 ile yeniden derlemeye çalıştım. Derleme düzgün çalışır, ancak konuşlandırıldığında Java.lang.VerifyError oluşur.

Yöntem adını değiştirip aşağıdaki hatayı aldığımda:

Java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMD signature: (IILjava/util/Collection;Lj    ava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/Apache/struts/util/MessageResources ØÅN|ØÅNÚw€mçw€mX#ÖM|XÔM
            at Java.lang.Class.getDeclaredConstructors0(Native Method)
            at Java.lang.Class.privateGetDeclaredConstructors(Class.Java:2357
            at Java.lang.Class.getConstructor0(Class.Java:2671)
            at Java.lang.Class.newInstance0(Class.Java:321)
            at Java.lang.Class.newInstance(Class.Java:303)

Daha fazla yöntem imzasının gösterildiğini görebilirsiniz.

Gerçek yöntem imzası

  private PgasePdfTable getMonthData(int month, int year, Collection dayTypes,
                          Collection calendarDays,
                          HashMap bcSpecialDays,
                          Collection activityPeriods,
                          Locale locale, MessageResources resources) throws   Exception {

Ben zaten javap ile bakmaya çalıştım ve bu yöntem gerektiği gibi imzasını veriyor.

Diğer meslektaşlarım kodu kontrol ettiğinde derleyin ve dağıtın, aynı problemi yaşarlar. Derleme sunucusu kodu alır ve geliştirme veya test ortamlarında (HPUX) dağıtırsa, aynı hata oluşur. Ayrıca Ubuntu çalıştıran otomatik bir test makinesi de sunucu başlangıcında aynı hatayı gösteriyor.

Uygulamanın geri kalanı tamam, sadece bir sunucu uygulamasının kullanım dışı olduğunu .. .. .. Nerede bakmak için herhangi bir fikir yardımcı olacaktır.

181
JeroenWyseur

Çalışma zamanında kullandığınızdan farklı bir kitaplığa karşı derlendiğiniz zaman Java.lang.VerifyError sonuç olabilir.

Örneğin, bu Xerces 1'e karşı derlenmiş bir programı çalıştırmaya çalışırken başıma geldi, ancak Xerces 2 sınıf yolunda bulundu. Gerekli sınıflar (org.Apache.* ad alanında) çalışma zamanında bulundu, bu nedenle ClassNotFoundException sonuç not idi. Sınıflarda ve yöntemlerde değişiklikler yapıldı, böylece çalışma zamanında bulunan yöntem imzaları derleme zamanında orada olanlarla eşleşmedi.

Normalde, derleyici yöntem imzalarının uyuşmadığı problemleri işaretler. JVM, sınıf yüklendiğinde bayt kodunu tekrar doğrular ve bayt kodu izin verilmemesi gereken bir şey yapmaya çalışırken VerifyError değerini atar. String değerini döndüren bir yöntemi çağırmak ve ardından o değeri döndüren bir List değerini alan bir alanda saklamak.

180
Kevin Panko

Java.lang.VerifyError en kötüsüdür.

Metodunuzun bytecode büyüklüğü 64kb sınırını aşıyorsa bu hatayı alırsınız; ama muhtemelen bunu fark etmişsinizdir.

Bu sınıfın uygulamanızın başka bir yerindeki sınıf yolunda, belki başka bir kavanozda bulunmadığından% 100 emin misiniz?

Ayrıca, yığın izlemenizden, kaynak dosyanın karakter kodlaması (utf-8?) Doğru mu?

20
p3t0r

Kevin Panko'nun dediği gibi, çoğunlukla kütüphane değişikliği yüzünden .Bu nedenle bazı durumlarda projenin "temizliği" (dizini) ve ardından bir derleme yapılır.

10
Flow

Bu hatayı Android'de, burada açıklandığı gibi bir kütüphane ithal ettiğim projeyi yaparak düzeltdim http://developer.Android.com/tools/projects/projects-Eclipse.html#SettingUpLibraryProject

Önceden, sadece projeye gönderme yapıyordum (kütüphane yapmıyordum) ve bu garip VerifyError'u alıyordum.

Umarım birine yardım eder.

8
Tiago

VerifyError, sınıf dosyasının sözdizimsel olarak doğru olan ancak bazı anlamsal kısıtlamaları ihlal ettiği gibi bytecode içerdiği anlamına gelir. yöntem sınırlarını geçen bir atlama hedefi.

Temel olarak, bir VerifyError yalnızca bir derleyici hatası olduğunda veya sınıf dosyası başka bir şekilde bozulduğunda (örneğin hatalı RAM veya başarısız bir HD aracılığıyla) oluşabilir.

Farklı bir JDK sürümüyle ve farklı bir makinede derlemeyi deneyin.

7

Deneyebileceğiniz bir şey, yükte bayt kodunu doğrulayan ve bayt kodu geçersizse bazen yararlı hata mesajları veren -Xverify:all kullanmaktır. 

7
Alex Miller

Benim durumumda Android projem Java 7 için derlenen başka bir Java projesine bağlı. Bu Java projesinin Derleyici Uyum Seviyesini 6.0 olarak değiştirdikten sonra Java.lang.VerifyError kayboldu

Daha sonra bunun bir Dalvik sorunu olduğunu öğrendim: https://groups.google.com/forum/?fromgroups#!topic/Android-developers/sKsMTZ42pwE

5
Michal Vician

Pack200'ün bir sınıf dosyasını yönetmesi nedeniyle bu sorunu yaşıyordum. Biraz arama bu Java bug up döndü. Temel olarak, --effort=4 ayarı problemin ortadan kalkmasına neden oldu.

Java 1.5.0_17'yi kullanma (Java 1.5'in her bir varyantında kırpılmış olmasına rağmen denedim).

4
Mike Miller

Oracle'ın JDK'sına karşı derlenmiş bir kütüphaneyi yüklemeye çalışırken Android'de bu olabilir.

İşte problem Ning Async HTTP istemcisi için.

2
Martin Konicek

Değiştirerek benzer bir Java.lang.VerifyError sorununu düzelttim

        catch (MagickException e)

ile

        catch (Exception e)

MagickException burada bir kütüphane projesinde tanımlandı (projemin bağımlı olduğu bir proje).

Ondan sonra aynı kütüphaneden bir sınıf hakkında bir Java.lang.NoClassDefFoundError aldım ( https://stackoverflow.com/a/9898820/755804 uyarınca).

2

Benim durumumda bu bloğu kaldırmak zorunda kaldım:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Fragment.showDialog() yöntem çağrısı yakınında hata gösteriyordu.

2
ViliusK

Hatayı üreten minimal örnek

Basit bir olasılık, Jasmin kullanmak veya bytecode'u bir ikili dosya editörü ile elle düzenlemek.

JVMS'nin yasadışı olduğunu söylediği void komutu (Java'daki return; ifadesi tarafından oluşturulan) olmadan return yöntemi oluşturalım.

Jasmin’de şunu yazabiliriz:

.class public Main
.super Java/lang/Object

.method public static main([Ljava/lang/String;)V
   aload_0 ; Just so that we won't get another verify error for empty code.
.end method

Daha sonra javac Main.j yapıyoruz ve javap -v Main derlediğimizi söylüyor:

public static void main(Java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=1, locals=1, args_size=1
       0: aload_0

yani gerçekten iade talimatı yoktur.

Şimdi Java Main komutunu çalıştırmayı denersek, şunu elde ederiz:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" Java.lang.VerifyError: (class: NoReturn, method: main signature: ([Ljava/lang/String;)V) Falling off the end of the code
        at Java.lang.Class.getDeclaredMethods0(Native Method)
        at Java.lang.Class.privateGetDeclaredMethods(Class.Java:2701)
        at Java.lang.Class.privateGetMethodRecursive(Class.Java:3048)
        at Java.lang.Class.getMethod0(Class.Java:3018)
        at Java.lang.Class.getMethod(Class.Java:1784)
        at Sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.Java:544)
        at Sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.Java:526)

Java derleyicisi bizim için return yöntemlerine örtük bir void işlevi eklediğinden, bu hata normal olarak Java'da gerçekleşemez. Bu nedenle, return metodlarımıza main eklememiz gerekmiyor. Bunu javap ile kontrol edebilirsiniz.

JVMS

VerifyError, JVMS 7 bölüm 4.5 tarafından belirtilen belirli türdeki yasadışı sınıf dosyalarını çalıştırmaya çalıştığınızda gerçekleşir.

JVMS, Java bir dosya yüklediğinde, sınıf dosyasının çalıştırılmadan önce tamam olduğunu görmek için bir dizi kontrol yapması gerektiğini söylüyor.

Tek bir derleme ve Java kodu çalıştırma döngüsünde bu hatalar üretilemez, çünkü JVMS 7 4.10 diyor ki :

Java programlama dili için bir derleyici yalnızca tüm statik ve yapısal kısıtlamaları karşılayan sınıf dosyaları üretse bile [... ]

Bu yüzden minimal bir başarısızlık örneği görmek için javac olmadan kaynak kodu oluşturmamız gerekecek.

Benim durumumda, A projem diğerine bağımlıydı, diyor X (A, X'te tanımlanan sınıfların bazılarını kullanıyordu). Bu yüzden, A'yı inşa yolunda referans proje olarak X eklediğimde bu hatayı aldım. Ancak başvurulan proje olarak X'i çıkardığımda ve X'in kavanozunu kütüphanelerden biri olarak eklediğimde sorun çözüldü.

1
user2484130

Bu sayfa size bazı ipuçları verebilir. - http://www.zanthan.com/itymbi/archives/000337.html

Javac'ın tespit edemediği bu yöntemin gövdesinde ince bir hata olabilir. Tüm yöntemi buraya göndermediğiniz sürece teşhis koymak zor. 

Zanthan sitesinde bahsedilen hatayı yakalayabilecek ... ve zaten her zaman iyi bir pratik olan ... mümkün olduğu kadar çok değişken bildirerek başlayabilirsiniz.

1
Lars Westergren

Java7'ye geçiyorsanız veya Java7 kullanıyorsanız, bu hata genellikle görülebilir. Hataların üstesinden geldim ve kök nedenini bulmak için çok uğraştım, uygulamanızı çalıştırırken "-XX: -UseSplitVerifier" JVM argümanını eklemeyi denerdim.

1
Ulhas N

Sınıfınızdaki aynı jar dosyasının birden fazla versiyonunu kontrol edin. 

Örneğin sınıf yolumda opennlp-tools-1.3.0.jar ve opennlp-tools-1.5.3.jar vardı ve bu hatayı aldım. Çözüm opennlp-tools-1.3.0.jar dosyasını silmek oldu.

1
demongolem

Bu hatanın bir başka nedeni AspectJ <= 1.6.11 ile JRE> 6'nın kombinasyonu olabilir.

Ayrıntılar için Eclipse Bug 353467 ve Kieker bilet 307 'a bakınız.

Bu özellikle JRE 6'da her şey yolunda gittiğinde ve JRE7'ye geçildiğinde bir şeyleri kırarsa geçerlidir. 

1
Alexander Wessel

Ayrıca, maven ..__ ile çok sayıda modül içe aktarma işlemi olduğunda da olabilir ..__Adı aynı ada sahip iki veya daha fazla sınıf olacak (aynı nitelikli isim) .. ve çalışma zamanı.

1
Toumi

JRE> 6 ile CGLIB <2.2, benzer hataları tetikleyebilir, bkz. "CGLIB 3.0'a yükseltme yapmalı mıyım?" ve Bahar SPR-9669 .

Bu, özellikle JRE 6'da her şey yolunda gittiğinde ve JRE7'ye geçmek bir şeyleri bozduğunda geçerlidir.

1
Alexander Wessel

Java.lang.VerifyError, derlenmiş bayt kodunuzun Android'in bulamadığı bir şeyden bahsettiği anlamına gelir. Bu verifyError Sadece KitKat4.4 ve daha düşük sürümlerle - yukarıdaki sürümde değil her ikisini de Aygıtlarda aynı yapıya koysam bile sorun yaratıyor. Ben eski sürüm jackson json ayrıştırıcı kullanıldığında Java.lang.verifyerror gösterir

compile 'com.fasterxml.jackson.core:jackson-databind:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-core:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-annotations:2.2.+'

Daha sonra, Dependancy'i- en son sürüm 2.2 ile 2.7 -//- core library olmadan değiştirdim, sonra çalışıyor. bu da core 'nin diğer içerikleri ve Databind2.7 ' nin son sürümüne geçirildiği anlamına gelir. Bu benim sorunlarımı düzeltir.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'
0
anand krish

lütfen kullanılamayan herhangi bir jar dosyasını kaldırın ve çalıştırmayı deneyin. ve onun için benim için bir jcommons jar dosyası ve ayrıca başka bir jcommons.1.0.14 jar dosyası ekledim, böylece jcommons ve bunun benim için çalışmasını kaldırın

0
Jat Rahul

Kevin'in bahsettiği sebep doğru olsa da, kesinlikle başka bir şeye geçmeden önce aşağıdakileri kontrol edeceğim:

  1. Sınıf yolumdaki cglibs dosyasını kontrol edin. 
  2. Sınıf yolumdaki hibernate sürümlerini kontrol edin.

Yukarıdakilerden herhangi birinin birden fazla veya birbiriyle çelişen bir sürümünün olmasının, söz konusu olan gibi beklenmeyen sorunlara neden olabileceği ihtimalleri iyi.

0
Sandeep Jindal