2011-06-03 16 views
7

Soy bastante inestable con las pruebas Unitarias pero tengo una parte de mi código. Realmente necesito estar seguro de su consistencia. Estoy intentando transferir datos de un objeto a un archivo externo usando JSON, así que quiero asegurarme de que cuando retire los datos del archivo externo será el mismo.Error de tiempo de ejecución cuando se prueban JUnit

Estoy usando una prueba de unidad para afirmar esta igualdad pero estoy encontrando un problema que no estoy seguro de cómo manejarlo. Es un error de tiempo de ejecución y esto es lo que lee la consola.

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 

Cualquier ayuda sería apreciada gracias.

+1

Duplicado: [Error grave por entorno de tiempo de ejecución Java] (http://stackoverflow.com/questions/2543106/fatal-error-by-java-runtime-environment) –

+0

@Tomasz Blachowicz tiene razón. comprobar si android. la mayor parte de Android obtiene dicho ERROR –

+0

Similar a [No se puede ejecutar el caso de prueba JUnit 4 en eclipse] (http://stackoverflow.com/questions/2172152/cant-run-junit-4-test-case-in-eclipse) – idbrii

Respuesta

2

Eso no tiene nada que ver con su código, que se parece a un error de JVM genuino para mí. La JVM nunca debería bloquearse así. Presente un informe de error con Oracle.

+0

Ok muchas gracias. Miré el archivo de registro para más detalles y es bastante detallado pero confuso. – Hugs

2

Supongo que está usando Android, porque la mayoría de las personas parecen tener problemas con Android y Junit.
Encontré esta entrada de blog donde discuten el tema en particular en la sección de comentarios. Uno de los comentarios menciona este error en particular. Puedes encontrar algo de ayuda aquí. http://dtmilano.blogspot.com/2008/11/android-testing-on-android-platform.html

Una de las opciones sugeridas es eliminar el directorio "bin" y "gen", y vuelva a intentarlo. ShouldNotReachhere classFileParser ANDROID

+0

Umm no, dice que JVM está usando, que no es el de Android. – Tnem

+1

@Tnem, vale, tengo que editar esto una vez más, tengo que tomar un café. Parece que JUNIT usa JVM –

+0

Dead on Estoy desarrollando una aplicación e intentando probarla. Tengo bastante experiencia en ambos tipos de pruebas unitarias y solo estaba intentando probar primero en Java. Esa es probablemente una mala forma de probar Android, pero realmente no estaba probando nada relacionado con Android. Gracias por la respuesta. Creo que voy a probar un proyecto de prueba. – Hugs

3

Si está utilizando Eclipse para desarrollar una aplicación de Android, aquí hay otra posible explicación: http://independentlyemployed.co.uk/2010/11/17/worked-out-why/. (Aparentemente, esto también puede ocurrir si intenta/ha intentado desarrollar Android y Java normal en el mismo Eclipse Workspace; consulte https://stackoverflow.com/a/3223929/139985)

Si no lo está, entonces creo que el problema general es que la JVM está cayendo mientras intenta analizar (probablemente cargar) un archivo de clase. La causa más probable parece ser que el archivo de la clase está destrozado de alguna manera. Si ese es el caso, entonces este no es un error de JVM. La JVM puede no tener más remedio que informar este tipo de problema a través de un informe de bloqueo, ya que podría ocurrir durante el arranque de JVM.


Aquí hay una entrada en la base de datos de errores de Java que informa lo siguiente: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032077. Desafortunadamente, se ha cerrado como no reproducible.

+1

Si hay un archivo de clase destrozado, la JVM debería arrojar una excepción adecuada quejándose de ello, no caerse de esta manera, por lo que podría decirse que sigue siendo un error. – artbristol

+0

@artbristol - He cubierto eso en las últimas 2 oraciones de mi respuesta. –

Cuestiones relacionadas