Crash JVM à cause de SIGSEGV

Description du signal

SIGSEGV, SIGBUS, SIGFPE, Sigpipe, Sigill - Utilisé dans la mise en œuvre pour la vérification null implicite, etc.

Support de vidage de fil SIGQUIT - Pour vider les traces de pile Java au flux d'erreur standard. (Facultatif.)

SIGTERM, SIGINT, SIGTERM - Utilisé pour supporter le mécanisme de crochet d'arrêt (java.lang.runtime.addshutdownhook) lorsque le VM est terminé anormalement. (Facultatif.)

SIGUSR1 - utilisé dans la mise en œuvre de la méthode Java.Lang.thread.Interrompt.Interrupt. (Configurable.) Non utilisé à partir de Solaris 10 OS. Réservé sur Linux. SIGUSR2 utilisé en interne. (Configurable.) Non utilisé à partir de Solaris 10 OS. SIGABRT Le hotspot vm ne gère pas ce signal. Au lieu de cela, il appelle la fonction d'avort après la manipulation des erreurs mortelles. Si une application utilise ce signal, il devrait terminer le processus pour préserver la sémantique attendue.

Le journal d'erreur fatal indique que l'accident était dans une bibliothèque indigène, il pourrait y avoir un bogue dans le code natif ou le code de la bibliothèque JNI. Le crash pourrait bien sûr être causé par quelque chose d'autre, mais l'analyse de la bibliothèque et de tout fichier de base ou du dépotoir de crash est une bonne place de départ.

Dans ce cas, un SIGSEGV s'est produit avec un fil d'exécution dans la bibliothèque libdtagentcore.so. Dans certains cas, un bogue dans une bibliothèque indigène se manifeste comme un crash dans le code Java VM. Considérez le crash suivant où une Javathread échoue dans l'état _thread_in_vm (ce qui signifie qu'il exécute dans le code Java VM)

• Si vous obtenez un crash dans une bibliothèque d'applications native (comme dans votre cas), vous pourrez peut-être associer le débogueur natif au fichier principal ou au dépotoir de crash, s'il est disponible. Selon le système d'exploitation, le débogueur natif est DBX, GDB ou WINDBG.
• Une autre approche consiste à courir avec l'option `-xcheck: jni` ajoutée à la ligne de commande. Cette option n'est pas garantie de trouver tous les problèmes avec le code JNI, mais cela peut aider à identifier un nombre important de problèmes.
• Si la bibliothèque native sur laquelle le crash est survenu fait partie de l'environnement d'exécution Java (par exemple, awt.dll, net.dll, etc.), il est possible que vous ayez rencontré une bibliothèque ou un bogue API. Si, après une analyse ultérieure, vous terminez, ceci est une bibliothèque ou un bogue API, puis rassemblez une quantité de données aussi possible et soumettez un bogue ou un appel d'assistance.

Il y a une situation accrocheuse dans le code JNI: lorsqu'un tel code bloque SIGSEGV Signal E.G. Parce qu'il bloque tous les signaux (approche assez courante du code C fileté sur la manière de s'assurer que seul le thread principal traitera des signaux) et il appelle Java vm (AKA rappel), il peut entraîner un assez aléatoire. SIGSEGV a déclenché l'abandon du processus.
Et il n'y a pratiquement rien de mal - SIGSEGV est réellement déclenché par Java VM afin de détecter certaines conditions en mémoire (elle sert de barrière de mémoire ... etc.) et il s'attend à ce qu'un tel signal soit géré par Java VM. Malheureusement, lorsque SIGSEGV est bloqué, la réaction SIGSEGV «standard» est déclenchée => Crashs de processus VM.