Causes possibles de Java VM EXCEPTION_ACCESS_VIOLATION?
Lorsqu'un Java VM se bloque avec un EXCEPTION_ACCESS_VIOLATION et produit un fichier hs_err_pidXXX.log, qu'est-ce que cela indique? L'erreur elle-même est essentiellement une exception de pointeur nul. cela est toujours causé par un bogue dans la machine virtuelle Java, ou y a-t-il d'autres causes telles que des conflits matériels ou logiciels défectueux?
Edit: il y a un composant natif, c'est une application SWT sur win32.
La plupart du temps, il s'agit d'un bogue dans la machine virtuelle. Mais cela peut être causé par n'importe quel code natif (par exemple, les appels JNI).
Le fichier hs_err_pidXXX.log doit contenir des informations sur l'origine du problème.
Vous pouvez également consulter la section "Tas" à l'intérieur du fichier. La plupart des bogues VM sont causés par le garbage collection (en particulier dans les machines virtuelles plus anciennes). Cette section devrait vous montrer si le garbage était en cours d'exécution au moment du plantage. Cette section indique également, si certaines sections du tas sont remplies (les nombres en pourcentage).
Le VM est également beaucoup plus susceptible de se bloquer dans une situation de mémoire faible qu'autrement.
Réponse trouvée!
J'ai eu la même erreur et j'ai remarqué que d'autres qui fournissaient le contenu du fichier journal pid exécutaient Windows 64 bits. Exactement comme moi. À la fin du fichier journal, il comprenait l'instruction PATH. Là, je pouvais voir que C:\Windows\SysWOW64 était incorrectement répertorié avant:% SystemRoot%\system32. Une fois que je l'ai corrigé, l'exception a disparu.
La première chose à faire est de mettre à niveau votre JVM vers la dernière version possible.
Pouvez-vous répéter le problème? Ou cela semble-t-il se produire au hasard? Nous avons récemment eu un problème où notre JVM plantait partout, à des moments aléatoires. Il s'avère que c'était un problème matériel. Nous avons mis les disques dans un nouveau serveur et il a complètement disparu.
En fin de compte, la JVM ne devrait jamais planter, comme l'affiche ci-dessus si vous ne faites aucun JNI, alors mon instinct est que vous avez un problème matériel.
La cause du problème sera documentée dans le fichier hs_err *, si vous savez quoi chercher. Jetez un coup d'œil, et si ce n'est toujours pas clair, pensez à publier les 5 ou 10 premières lignes de la trace de la pile et d'autres informations pertinentes (ne postez pas le tout, il y a des tonnes d'informations là-dedans qui n'aideront pas - mais vous devez déterminer quel 1% est important :-))
J'ai le même problème avec une application JNLP que j'utilise depuis longtemps et qui est assez fiable. Le problème a commencé immédiatement après la mise à niveau de Windows 7 vers Windows 10. Selon mon enquête, il s'agit très probablement d'un bogue dans Win 10.
Ce qui suit n'est pas une solution, mais une solution de contournement laide. Dans le répertoire jre/bin, il y a javaws.exe. Si je clique avec le bouton droit / Propriétés/Compatibilité et coche Exécute ce programme en tant qu'administrateur, l'application JNLP a commencé à fonctionner.
Veuillez noter que cette approche peut entraîner des problèmes de sécurité et ne l'utilisez que si vous n'avez pas d'autre option et que vous savez à 100% ce que vous faites.
Utilisez-vous un widget Navigateur et exécutez-vous du javascript dans le widget Navigateur? Si tel est le cas, il existe des bogues dans certaines versions de SWT qui provoquent le blocage de la JVM dans le code natif, dans diverses bibliothèques Windows.
Deux exemples (que j'ai ouverts) sont bug 217306 et bug 12796 . Cependant, ces deux rapports de bogues ne sont pas les seuls rapports de bogues de la panne de la JVM dans SWT.
Si vous n'utilisez pas le widget Navigateur, ces suggestions ne vous aideront pas. Dans ce cas, vous pouvez rechercher une liste de bogues SWT provoquant un crash JVM . Si aucun de ces problèmes ne vous concerne, je vous recommande fortement d'ouvrir un rapport de bogue avec SWT.