Błąd wykonania podczas testowania JUnit

Jestem dość drżący z testowaniem Jednostki, ale mam część mojego kodu, naprawdę muszę być pewny jego spójności. Próbuję przesłać dane z obiektu do zewnętrznego pliku przy użyciu JSON, więc chcę się upewnić, że po pobraniu danych z zewnętrznego pliku będzie to samo.Błąd wykonania podczas testowania JUnit

Używam testu jednostek, aby potwierdzić tę równość, ale napotykam problem, którego nie jestem pewien. Jest to błąd środowiska wykonawczego i właśnie to odczytuje konsola.

A fatal error has been detected by the Java Runtime Environment: 

Internal Error (classFileParser.cpp:3494), pid=5032, tid=7048 
Error: ShouldNotReachHere() 

JRE version: 6.0_25-b06 
Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode windows-amd64 compressed oops) 
An error report file with more information is saved as: 
L:\fliphouseWorkspace\Luas\hs_err_pid5032.log 

If you would like to submit a bug report, please visit: 
http://java.sun.com/webapps/bugreport/crash.jsp

Każda pomoc zostanie doceniona dzięki.

Źródło

2011-06-03 Hugs

Duplikat: [Błąd krytyczny w środowisku wykonawczym Java] (http://stackoverflow.com/questions/2543106/fatal-error-by-java-runtime-environment) –

@Tomasz Blachowicz ma rację. sprawdź, czy Android. większość Androida dostaje taki ERROR –

Podobne do [Nie można uruchomić testu JUnit 4 w Eclipse] (http://stackoverflow.com/questions/2172152/cant-run-junit-4-test-case-in-eclipse) – idbrii

To nie ma nic wspólnego z kodem, który wygląda jak prawdziwy błąd JVM. Maszyna JVM nigdy nie powinna się tak rozbić. Złóż raport o błędzie w Oracle.

Źródło

2011-06-03 12:30:09

Ok, dziękuję bardzo. Spojrzałem na plik logu, aby uzyskać więcej szczegółów i jest to dość szczegółowe, ale mylące. – Hugs

Zakładam, że używasz Androida, ponieważ większość ludzi ma problemy z Androidem i zjednoczeniem.
Znalazłem ten wpis na blogu, na którym omawiają dany problem w sekcji komentarzy. Jeden z komentarzy wspomina ten konkretny błąd. Możesz znaleźć tutaj pomoc. http://dtmilano.blogspot.com/2008/11/android-testing-on-android-platform.html

Jedną z sugerowanych opcji jest usunięcie katalogu "bin" i "gen" i spróbuj ponownie. ShouldNotReachhere classFileParser ANDROID

Źródło

2011-06-03 12:30:19

Umm nie, mówi, z którego JVM korzysta, co nie jest androidem. – Tnem

@Tnem, ok, muszę to jeszcze raz edytować, muszę napić się kawy. Wygląda na to, że JUNIT używa JVM –

Dead w trakcie tworzenia aplikacji i próbowania jej przetestowania. Jestem dość niedoświadczony w obu rodzajach testów jednostkowych i najpierw próbowałem tylko testować w Javie. To chyba zły sposób na testowanie Androida, ale tak naprawdę nie testowałem nic z Androidem. Dziękuję za odpowiedź. Myślę, że zdobędę test testowy. – Hugs

Jeśli używasz Eclipse do opracowania aplikacji dla systemu Android, oto inne możliwe wyjaśnienie: http://independentlyemployed.co.uk/2010/11/17/worked-out-why/. (Wydaje się, że może się to również zdarzyć, jeśli spróbujesz/próbowałeś stworzyć Androida i zwykłą Javę w tym samym Eclipse Workspace, zobacz https://stackoverflow.com/a/3223929/139985)

Jeśli nie, to myślę, że ogólny problem polega na tym, że JVM spada podczas próby sparsowania (prawdopodobnie wczytania) pliku klasy. Najbardziej prawdopodobną przyczyną wydaje się być, że plik klasy jest w jakiś sposób sfałszowany. Jeśli tak jest, to nie jest błąd JVM. JVM może nie mieć innego wyjścia, jak zgłosić ten problem poprzez raport o awariach, ponieważ może się to zdarzyć podczas ładowania systemu JVM.

Oto wpis w Bazie danych błędów Java, który zgłasza to: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032077. Niestety został zamknięty, ponieważ nie można go odtworzyć.

Źródło

2011-06-03 13:34:42

Jeśli istnieje zmanipulowany plik klasy, JVM powinna wypchnąć odpowiedni wyjątek narzekając na niego, nie upuszczając go w ten sposób, więc prawdopodobnie nadal jest to błąd. – artbristol

@artbristol - Omówiłem to w dwóch ostatnich zdaniach z mojej odpowiedzi. –

Błąd wykonania podczas testowania JUnit

Odpowiedz

Powiązane problemy