java - nazareno - jni logo
JNA está causando EXCEPTION_ACCESS_VIOLATION? (4)
Mi UI de Java inesperadamente finalizó y descargó un archivo hs_err_pid . El archivo dice "El bloqueo ocurrió fuera de la Máquina Virtual Java en código nativo". JNA es el único código nativo que usamos. ¿Alguien sabe de algún problema conocido o error con cualquier versión de JNA que pueda causar esto? He incluido algunos de los contenidos del archivo de error a continuación.
An unexpected error has been detected by Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d02bcbd, pid=312, tid=3616
Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing windows-x86)<br>
Problematic frame:
C [awt.dll+0x2bcbd]
If you would like to submit a bug report, please visit:
http://java.sun.com/webapps/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
Current thread (0x02acf000): JavaThread "AWT-Windows" daemon [_thread_in_native, id=3616, stack(0x02eb0000,0x02f00000)]
siginfo: ExceptionCode=0xc0000005, writing address 0xe2789280
Registers:
EAX=0x234f099c, EBX=0x00001400, ECX=0x00000100, EDX=0xe2789280
ESP=0x02eff4a4, EBP=0x00000400, ESI=0x234f099c, EDI=0xe2789280
EIP=0x6d02bcbd, EFLAGS=0x00010206
Top of Stack: (sp=0x02eff4a4)
0x02eff4a4: 02eff500 00000100 02eff584 00000100
0x02eff4b4: 6d0a5697 00000400 00000400 00000100
0x02eff4c4: 00000100 02eff700 02eff500 00000000
0x02eff4d4: 00000000 00000100 041ac3a0 00000100
0x02eff4e4: 00182620 00000400 e2789280 00000000
0x02eff4f4: 00000000 00000100 00000100 00000000
0x02eff504: 00000000 00000100 00000100 00000000
0x02eff514: 00000000 00000004 00000400 00000000
Instructions: (pc=0x6d02bcbd)
0x6d02bcad: 00 00 00 8b 4c 24 14 8b e9 c1 e9 02 8b f0 8b fa
0x6d02bcbd: f3 a5 8b cd 83 e1 03 f3 a4 8b 74 24 18 8b 4c 24
Stack: [0x02eb0000,0x02f00000], sp=0x02eff4a4, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [awt.dll+0x2bcbd]
[error occurred during error reporting (printing native stack), id 0xc0000005]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.awt.windows.WToolkit.eventLoop()V+0
j sun.awt.windows.WToolkit.run()V+69
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
A juzgar por:
Stack: [0x02eb0000,0x02f00000], sp=0x02eff4a4, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [awt.dll+0x2bcbd]
(en ese punto, aparentemente el rastro de la pila explotó) es posible que esté golpeando un error en la biblioteca AWT.
Ha accedido a una infracción de acceso, lo que significa que algún código intentó acceder a una dirección a la que no está permitido, a menudo porque no hay memoria en la dirección especificada. El stacktrace apunta a la ubicación que tropezó con el problema, que puede o no ser la fuente del problema. A veces las personas se olvidan de esto cuando hablan de código nativo, incluso si lo conocen de otra manera.
He usado JNA, pero nunca tuve ningún problema con eso. Si hubo una violación de acceso, fue mi culpa. Aquí hay algunos consejos simples.
Asegúrese de que su máquina esté físicamente sana. Pon a prueba tu memoria con Memtest86 + . No sirve de nada buscar un error de software si se trata de un problema de hardware.
Mire el código usando JNA. Tenga en cuenta que incluso si las llamadas en Java parecen poco visibles, está escribiendo un código de bajo nivel que puede meterse con cualquier cosa. Muy posible, el código que utiliza el JNA hace algo mal y corrompe la memoria. Por ejemplo, asegúrese de que se utiliza la convención de llamada correcta y la alineación de datos. En caso de duda, consiga a alguien que se sienta cómodo con C (o, más general, cosas de bajo nivel) para que lo ayude.
No descarte por completo otros factores. Puede ser que golpee un error de JVM o algo, pero tenga cuidado de qué tan probable es esto. Si oyes pezuñas, piensa en caballos, no en cebras.
Solo porque el único código nativo que utiliza a sabiendas es JNI / lo que no significa que un accidente como el suyo está relacionado con él en el lugar o en el tiempo. Hay todo tipo de soporte nativo usado silenciosamente en cualquier JVM / ejecución, y en un momento tuve extraños bloqueos causados al final por la corrupción que había sucedido mucho antes y por la propia JVM.
En mi caso, estaba encontrando errores interesantes en el enhebrado del GC simultáneo en mi nueva caja brillante multi-CPU (Niagara), que dejaba todo tipo de bombas esperando para estallar, y no tenía código nativo que no fuera JDK en mi aplicación en absoluto.
Cuando el equipo de GC de Sun arregló su error (y muy amablemente me proporcionó una VM de prueba de bootleg), mis problemas se evaporaron (bueno, después de una ronda o dos, naturalmente).
Rgds
Damon
Acabo de acertar con ese mismo error, en apariencia es un error en la nueva funcionalidad acelerada de Java2d de Direct3d con 1.6.0_11 que ocurre con máquinas con baja memoria RAM de video. Si inicia su aplicación con -Dsun.java2d.d3d = false, debería funcionar de nuevo. El error de seguimiento del sol es el siguiente: http://bugs.sun.com/view_bug.do?bug_id=6788497