Vous pouvez éventuellement obtenir des fichiers de vidage système, même en présence d'une situation
de concurrence.
A propos de cette tâche
Lorsque vous déterminez qu'il existe une situation de concurrence dans laquelle
la chronologie d'arrêt ou de fermeture du système empêche la création d'un vidage système, vous pouvez essayer d'obtenir un fichier de vidage de
deux manières :
- Essayez d'empêcher le système de s'arrêter avant que le fichier de vidage ne soit créé.
- Ajoutez un délai vers la fin de l'exécution de la JVM pour donner le temps au gestionnaire
des vidages d'écrire les fichiers de vidage.
Procédure
- AIX®, z/OS®ou Linux®: Créez un vidage système à l'aide de l'option de ligne de commande -Xrs Java™ pour désactiver le gestionnaire de signaux Java. Le gestionnaire de signaux par défaut dans le
système d'exploitation déclenche un vidage et empêche le système de s'arrêter avant que le fichier de vidage
ne soit créé. Pour plus d'informations, voir Option -Xrs.
- Sous Windows, vous ne pouvez pas utiliser l'option -Xrs pour collecter un fichier de vidage système dans cette situation car le système de vidage Windows permet au processus de s'arrêter pendant l'écriture du fichier de vidage. Utilisez à la place l'option -Xtrace:trigger pour ajouter un
délai vers la fin de l'exécution de la machine virtuelle. Ce délai laissera suffisamment de temps au gestionnaire des vidages pour écrire le fichier de vidage système. Pour plus d'informations, voir l'action de déclencheur sleep dans -Xtrace:trigger.
Lorsque l'action de déclenchement
sleep est ajoutée, la
sortie de console est similaire au texte suivant :
java -Xtrace:none,print=tpnid{j9vm.381-394},trigger=tpnid{j9vm.389,sleep} MyApp
11:16:50.234*0x42cc1a00 j9vm.385 > protectedDestroyJavaVM
11:16:50.234 0x42cc1a00 j9vm.386 - protectedDestroyJavaVM waiting for Java threads to
stop
11:16:50.234 0x42cc1a00 j9vm.387 - protectedDestoryJavaVM all Java threads have stopped
11:16:50.234 0x42cc1a00 j9vm.388 - protectedDestroyJavaVM protectedDestroyJavaVM
vmCleanup complete
TRCx289: Trace sleep action triggered. Sleeping for 30000 ms.
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 ExceptionCode=c0000005 ExceptionAddress=430514BE ContextFlags=0001003f
Handler1=7FEE9C40 Handler2=7FEC98C0 InaccessibleAddress=00000000
EDI=000A70E0 ESI=4333BB28 EAX=00000000 EBX=001926B4
ECX=00000001 EDX=4368FECC
EIP=430514BE ESP=4368FED4 EBP=4368FED8 EFLAGS=00010246
Module=failing_module.dll
Module_base_address=43050000 Offset_in_DLL=000014be
Target=2_40_20081203_026494_lHdSMr (Windows XP 5.1 build 2600 Service Pack 2)
CPU=x86 (2 logical CPUs) (0x7fe6b000 RAM)
----------- Stack Backtrace -----------
_crash:0x430514BE [0x430514B0 +0x0000000E]
_agent_thread_run:0x430513AD [0x430513A0 +0x0000000D]
J9VMDllMain:0x7FCA6F70 [0x7FCA5820 +0x00001750]
0x001926B4
0x430E0100
---------------------------------------
JVMDUMP006I Processing dump event "gpf", detail "" - please wait.
JVMDUMP007I JVM Requesting System dump using 'C:\java\pwi3260sr4-20081205_01\core.20081208.111651.5344.
0001.dmp'
JVMDUMP010I System dump written to C:\java\pwi3260sr4-20081205_01\core.20081208.111651.5344.0001.dmp
JVMDUMP007I JVM Requesting Snap dump using 'C:\java\pwi3260sr4-20081205_01\Snap.20081208.111651.5344.
0002.trc'
JVMDUMP012E Error in Snap dump: {nothing to snap}
JVMDUMP007I JVM Requesting Java dump using 'C:\java\pwi3260sr4-20081205_01\javacore.20081208.111651.5344.
0003.txt'
JVMDUMP010I Java dump written to C:\java\pwi3260sr4-20081205_01\javacore.20081208.111651.5344.0003.txt
JVMDUMP013I Processed dump event "gpf", detail "".