Java runtime environment error log

A Fatal Error Log

Describes the fatal error log, its location, and contents.

The fatal error log is created when a fatal error occurs. It contains information and the state obtained at the time of the fatal error.

The format of this file can change slightly in update releases.

This appendix contains the following sections:

Location of Fatal Error Log

To specify where the log file will be created, use the product flag -XX:ErrorFile= file , where file represents the full path for the log file location.

The substring %% in the file variable is converted to % , and the substring %p is converted to the PID of the process.

In the following example, the error log file will be written to the directory /var/log/java and will be named java_error pid .log :

If the -XX:ErrorFile=file flag is not specified, then the default log file name is hs_err_ pid .log , where pid is the PID of the process.

In addition, if the -XX:ErrorFile=file flag is not specified, the system attempts to create the file in the working directory of the process. In the event that the file cannot be created in the working directory (insufficient space, permission problem, or other issue), the file is created in the temporary directory for the operating system. On the Oracle Solaris and Linux operating systems, the temporary directory is /tmp . On the Windows, the temporary directory is specified by the value of the TMP environment variable. If that environment variable is not defined, then the value of the TEMP environment variable is used.

Description of Fatal Error Log

Description of the fatal error log file and the sections that contain information obtained at the time of the fatal error.

The error log contains information obtained at the time of the fatal error, including the following information, where possible:

The operating exception or signal that provoked the fatal error

Version and configuration information

Details about the thread that provoked the fatal error and the thread’s stack trace

List of running threads and their states

Summary information about the heap

List of native libraries loaded

Details about the operating system and CPU

In some cases only a subset of this information is output to the error log. This can happen when a fatal error is of such severity that the error handler is unable to recover and report all the details.

The error log is a text file consisting of the following sections:

A header that provides a brief description of the crash. See Header Format.

A section with thread information. See Thread Section Format.

A section with process information. See Process Section Format.

A section with system information. See System Section Format.

The format of the fatal error log described here is based on Java SE 6. The format might be different with other releases.

The header section at the beginning of every fatal error log file contains a brief description of the problem.

The header is also printed to standard output and may show up in the application’s output log.

The header includes a link to the HotSpot Virtual Machine Error Reporting Page, where the user can submit a bug report.

The example shows that the VM crashed on an unexpected signal.

The next line describes the signal type, program counter (pc) that caused the signal, process ID, and thread ID, as shown in the following example.

The next line contains the VM version (client VM or server VM), an indication of whether the application was run in mixed or interpreted mode, and an indication of whether class file sharing was enabled, as shown in the following line.

The next information is the function frame that caused the crash, as shown in the following example.

In this example, the «C» frame type indicates a native C frame. Table A-1 shows the possible frame types.

Table A-1 Frame Types

Interpreted Java frame

VM-generated stub frame

Other frame types, including compiled Java frames

Internal errors will cause the VM error handler to generate a similar error dump. However, the header format is different. Examples of internal errors are guarantee() failure, assertion failure, ShouldNotReachHere() , and so forth. The following example shows the header format for an internal error.

In the above header, there is no signal name or signal number. Instead the second line now contains Internal Error and a long hexadecimal string. This hexadecimal string encodes the source module and line number where the error was detected. In general this «error string» is useful only to engineers working on the HotSpot Virtual Machine.

The error string encodes a line number and therefore it changes with each code change and release. A crash with a given error string in one release (for example, 1.6.0) might not correspond to the same crash in an update release (for example, 1.6.0_01), even if the strings match.

Do not assume that a workaround or solution that worked in one situation associated with a given error string will work in another situation associated with that same error string. Note the following facts:

Errors with the same root cause might have different error strings.

Errors with the same error string might have completely different root causes.

Therefore, the error string should not be used as the sole criterion when troubleshooting bugs.

Thread Section Format

Information about the thread that crashed.

If multiple threads crash at the same time, then only one thread is printed.

The first part of the thread section shows the thread that caused the fatal error, as shown in the following example.

The thread pointer is the pointer to the Java VM internal thread structure. It is generally of no interest unless you are debugging a live Java VM or core file.

The following list shows possible thread types.

Table A-2 shows the important thread states.

Table A-2 Thread States

Frame Type	Description

Thread is not created. This occurs only in the case of memory corruption.

Thread was created, but it has not yet started.

Thread is running native code. The error is probably a bug in the native code.

Thread is running VM code.

Thread is running either interpreted or compiled Java code.

Thread is blocked.

If any of the previous states is followed by the string _trans , then that means that the thread is changing to a different state.

The thread ID in the output is the native thread identifier.

If a Java thread is a daemon thread, then the string daemon is printed before the thread state.

The next information in the error log describes the unexpected signal that caused the VM to terminate. On a Windows system the output appears as shown in the following example.

In the above example, the exception code is 0xc0000005 ( ACCESS_VIOLATION ), and the exception occurred when the thread attempted to read address 0xd8ffecf1 .

On Oracle Solaris and Linux operating systems the signal number ( si_signo ) and signal code ( si_code ) are used to identify the exception, as follows:

The next information in the error log shows the register context at the time of the fatal error. The exact format of this output is processor-dependent. The following example shows output for the Intel(R) Xeon(R) processor.

The register values might be useful when combined with instructions, as described below.

After the register values, the following example shows the error log that contains the top of stack followed by 32 bytes of instructions (opcodes) near the program counter (PC) when the system crashed. These opcodes can be decoded with a disassembler to produce the instructions around the location of the crash. Note: IA32 and AMD64 instructions are variable in length, and so it is not always possible to reliably decode instructions before the crash PC.

Where possible, the next output in the error log is the thread stack, as shown in the following example. This includes the addresses of the base and the top of the stack, the current stack pointer, and the amount of unused stack available to the thread. This is followed, where possible, by the stack frames, and up to 100 frames are printed. For C/C++ frames, the library name may also be printed. Note: In some fatal error conditions, the stack may be corrupt, and this detail may not be available.

The log contains two thread stacks.

The first thread stack is Native frames , which prints the native thread showing all function calls. However, this thread stack does not take into account the Java methods that are inlined by the runtime compiler; if methods are inlined, then they appear to be part of the parent’s stack frame.

The information in the thread stack for native frames provides important information about the cause of the crash. By analyzing the libraries in the list from the top down, you can generally determine which library might have caused the problem and report it to the appropriate organization responsible for that library.

The second thread stack is Java frames , which prints the Java frames including the inlined methods, skipping the native frames. Depending on the crash, it might not be possible to print the native thread stack, but it might be possible to print the Java frames.

If the error occurred in the VM thread or in a compiler thread, then further details may be seen from the following example. For example, in the case of the VM thread, the VM operation is printed if the VM thread is executing a VM operation at the time of the fatal error. In the following output example, the compiler thread caused the fatal error. The task is a compiler task, and the HotSpot Client VM is the compiling method hs101t004Thread.ackermann .

For the HotSpot Server VM, the output for the compiler task is slightly different but will also include the full class name and method.

Process Section Format

The process section is printed after the thread section.

It contains information about the whole process, including the thread list and memory usage of the process.

The thread list includes the threads that the VM is aware of, as shown in the following example.

This includes all Java threads and some VM internal threads, but does not include any native threads created by the user application that have not attached to the VM, as shown in the following example.

The thread type and thread state are described in Thread Section Format.

The next information is the VM state, which indicates the overall state of the virtual machine. Table A-3 describes the general states.

Table A-3 VM States

Thread State	Description

not at a safepoint

All threads are blocked in the VM waiting for a special VM operation to complete.

A special VM operation is required, and the VM is waiting for all threads in the VM to block.

The VM state output is a single line in the error log, as follows:

Mutexes and Monitors

The next information in the error log is a list of mutexes and monitors that are currently owned by a thread, as shown in the following example. These mutexes are VM internal locks rather than monitors associated with Java objects. The following is an example to show how the output might look when a crash happens when VM locks are held. For each lock, the log contains the name of the lock, its owner, and the addresses of a VM internal mutex structure and its OS lock. In general, this information is useful only to those who are very familiar with the HotSpot VM. The owner thread can be cross-referenced to the thread list.

The next information is a summary of the heap, as shown in the following example. The output depends on the garbage collection (GC) configuration. In this example, the serial collector is used, class data sharing is disabled, and the tenured generation is empty. This probably indicates that the fatal error occurred early or during startup, and a GC has not yet promoted any objects into the tenured generation.

The next information in the log is a list of virtual memory regions at the time of the crash. This list can be long if the application is large. The memory map can be very useful when debugging some crashes, because it can tell you which libraries are actually being used, their location in memory, as well as the location of the heap, stack, and guard pages.

Most of the lines were omitted from the example for the sake of brevity.

The following is a format of memory map in the error log.

The example shows the memory map output and each library has two virtual memory regions: one for code and one for data. The permission for the code segment is marked with r-xp (readable, executable, private), and the permission for the data segment is rw-p (readable, writable, private).

The Java heap is already included in the heap summary earlier in the output, but it can be useful to verify that the actual memory regions reserved for the heap match the values in the heap summary and that the attributes are set to rwxp .

Thread stacks usually show up in the memory map as two back-to-back regions, one with permission —p (guard page) and one with permission rwxp (actual stack space). In addition, it is useful to know the guard page size or stack size. For example, in this memory map, the stack is located from 4127b000 to 412fb000.

On a Windows system, the memory map output is the load and end address of each loaded module, as shown in the following example.

VM Arguments and Environment Variables

The next information in the error log is a list of VM arguments, followed by a list of environment variables, as shown in the following example.

The list of environment variables is not the full list but rather a subset of the environment variables that are applicable to the Java VM.

On the Oracle Solaris and Linux operating systems, the next information in the error log is the list of signal handlers, as shown in the following example.

System Section Format

The final section in the error log is the system information. The output is operating-system-specific but in general includes the operating system version, CPU information, and summary information about the memory configuration.

The following example shows output on a Linux operating system.

On the Oracle Solaris and Linux, the operating system, information is in the file /etc/*release . This file describes the kind of system the application is running on, and in some cases, the information string might include the patch level. Some system upgrades are not reflected in the /etc/*release file. This is especially true on the Linux system, where the user can rebuild any part of the system.

On Oracle Solaris operating system the uname system call is used to get the name for the kernel. The thread library (T1 or T2) is also printed.

On the Linux system, the uname system call is also used to get the kernel name. The libc version and the thread library type are also printed, as shown in the following example.

On Linux, there are three possible thread types, namely linuxthreads (fixed stack) , linuxthreads (floating stack) , and NPTL . They are normally installed in /lib , /lib/i686 , and /lib/tls .

It is useful to know the thread type. For example, if the crash appears to be related to pthread , then you might be able to work around the issue by selecting a different pthread library. A different pthread library (and libc ) can be selected by setting LD_LIBRARY_PATH or LD_ASSUME_KERNEL .

The glibc version usually does not include the patch level. The command rpm -q glibc might provide more detailed version information.

The default stack size of the VM is usually smaller than the system limit, as shown in the following example.

The next information specifies the CPU architecture and capabilities identified by the VM at startup, as shown in the following example.

Table A-4 shows the possible CPU features on a SPARC system.

Table A-4 SPARC Features

General VM State	Description

Supports v8 instructions.

Supports v9 instructions.

Supports visualization instructions.

Supports visualization instructions.

No hardware integer multiply and divide.

No multiply-add and multiply-subtract instructions.

Table A-5 shows the possible CPU features on an Intel/IA32 system.

Table A-5 Intel/IA32 Features

SPARC Feature	Description

Supports cmov instruction.

Supports cmpxchg8b instruction.

Supports fxsave and fxrstor.

Supports SSE extensions.

Supports SSE2 extensions.

Supports Hyper-Threading Technology.

Table A-6 shows the possible CPU features on an AMD64/EM64T system.

Table A-6 AMD64/EM64T Features

Intel/IA32 Feature	Description

AMD Opteron, Athlon64, and so forth.

Intel EM64T processor.

Supports 3DNow extension.

Supports Hyper-Threading Technology.

The next information in the error log is memory information, as shown in the following example.

Some systems require swap space to be at lease twice the size of real physical memory, whereas other systems do not have any requirements. As a general rule, if both physical memory and swap space are almost full, then there is good reason to suspect that the crash was due to insufficient memory.

On Linux system, the kernel may convert most of unused physical memory to file cache. When there is a need for more memory, the Linux kernel will give the cache memory back to the application. This is handled transparently by the kernel, but it means that the amount of unused physical memory reported by the fatal error handler could be close to zero when there is still sufficient physical memory available.

Источник

Adblock
detector

AMD64/EM64T Feature	Description

В последние два дня служба в тестовой среде всегда зависает (раз в два-три дня), а виртуальная машина JVM всегда дает сбой. Итак, необходимо понять причину сбоя JVM.

Когда JVM дает сбой из-за фатальной ошибки, создается файл, например hs_err_pid_xxx.log. Этот файл содержит важную информацию, которая вызвала сбой JVM. Мы можем определить причину сбоя JVM, проанализировав файл, тем самым исправив и обеспечив стабильность системы.

По умолчанию файл создается в рабочем каталоге, конечно, вы также можете указать путь генерации через параметр JVM:

-XX:ErrorFile=/var/log/hs_err_pid<pid>.log

Этот файл в основном содержит следующее содержимое:

• Заголовочный файл журнала
• Информация о потоке, вызвавшая сбой
• Вся информация о потоках
• Информация о точке безопасности и замке
• Информация о куче
• Кеш локального кода
• Скомпилировать событие
• записи, связанные с gc
• карта памяти jvm
• параметры запуска jvm
• информация о сервере

Вот пошаговый анализ, основанный на содержании этого файла.

Заголовочный файл журнала

Содержание выглядит следующим образом

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000003797807a91, pid=29071, tid=139901421901568
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

В этом параграфе в основном кратко описаны причины сбоя JVM. Общие причины включают ошибки JVM, ошибки приложений, параметры JVM, недостаточные ресурсы сервера, ошибки вызовов JNI и т. Д. Конечно, есть информация о версии и конфигурации,

SIGSEGV (0xb) at pc=0x0000003797807a91, pid=29071, tid=139901421901568

JRE обнаружила непредвиденную ошибку, где

• SIGSEGV: семафор
• 0xb: сигнальный код
• pc = 0x0000003797807a91: значение программного счетчика
• pid = 29071: ID процесса
• tid = 139901421901568: номер потока

SIGSEGV (0xb) означает, что код JNI выполняется при сбое JVM, общие описания включаютEXCEPTION_ACCESS_VIOLATION, Это описание указывает, что собственный код JVM выполняется при сбое JVM, что часто вызвано ошибкой в ​​JVM; другое общее описаниеEXCEPTION_STACK_OVERFLOW, Описание указывает, что это ошибка, вызванная переполнением стека, которое часто вызывается глубокой рекурсией в приложении.

# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops)

Информация о версиях JRE и JVM

# Problematic frame:
# C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1

Эта информация более важна, информация о проблемном кадре:

C Указывает, что тип кадра является локальным кадром, и существуют другие типы:

• j: Интерпретируемый фрейм Java
• V: фрейм виртуальной машины
• v: фрейм стека-заглушки, сгенерированный виртуальной машиной
• J: другие типы фреймов, включая скомпилированные фреймы Java

[libresolv.so.2+0x7a91] __libc_res_nquery+0x1c1Он имеет то же значение, что и программный счетчик (pc), но использует локальную библиотеку so + смещение.

Информация о потоке, вызвавшая сбой

Содержание выглядит следующим образом:

---------------  T H R E A D  ---------------

Current thread (0x0000000001e94800):  JavaThread "pool-1-thread-2" [_thread_in_native, id=30111, stack(0x00007f3d567e5000,0x00007f3d568e6000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000003

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x0000000000000000, RDX=0x0000000000000050
RSP=0x00007f3d568e2280, RBP=0x00007f3d568e2570, RSI=0x0000000000000000, RDI=0x00000000ffffffff
R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x000000000007a337, R11=0x0000000000000213
R12=0x00007f3d568e2ef0, R13=0x00007f3d568e22b0, R14=0x0000000000000000, R15=0x00007f3d568e5db8
RIP=0x0000003797807a91, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f3d568e2280)
0x00007f3d568e2280:   b8e4bfb900000800 00007f3d568e3760
0x00007f3d568e2290:   00007f3d568e3758 00007f3d568e377c
0x00007f3d568e22a0:   00007f3d568e3778 6f6e6b6e56a88a58
0x00007f3d568e22b0:   00000100000149a0 7a68710800000000
0x00007f3d568e22c0:   6970067363642d78 6d6f63036e61676e
.... опущено

Instructions: (pc=0x0000003797807a91)
0x0000003797807a71:   48 89 45 b8 48 8b 4d b8 0f b6 51 03 89 d3 83 e3
0x0000003797807a81:   0f 75 0d 0f b7 49 06 66 c1 c9 08 66 85 c9 75 4f
0x0000003797807a91:   0f b6 48 03 bf 0f 00 00 00 40 20 cf 75 0d 0f b7
0x0000003797807aa1:   70 06 66 c1 ce 08 66 85 f6 75 34 83 e1 0f 83 e2 

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x0000000000000000 is an unknown value
RDX=0x0000000000000050 is an unknown value
RSP=0x00007f3d568e2280 is pointing into the stack for thread: 0x0000000001e94800
RBP=0x00007f3d568e2570 is pointing into the stack for thread: 0x0000000001e94800
 ... опущено


Stack: [0x00007f3d567e5000,0x00007f3d568e6000],  sp=0x00007f3d568e2280,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
C  [libresolv.so.2+0x7fd1]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 15056  java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress; (0 bytes) @ 0x00007f3d7492af8c [0x00007f3d7492af40+0x4c]
J 14966 C1 java.net.InetAddress.getAddressesFromNameService(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (245 bytes) @ 0x00007f3d75466754 [0x00007f3d754662c0+0x494]
J 14291 C2 java.net.InetAddress.getAllByName(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (387 bytes) @ 0x00007f3d7534b718 [0x00007f3d7534ae20+0x8f8]
J 14178 C1 java.net.InetSocketAddress.<init>(Ljava/lang/String;I)V (47 bytes) @ 0x00007f3d752ce0f4 [0x00007f3d752cdec0+0x234]
j  sun.security.ssl.SSLSocketImpl.<init>(Lsun/security/ssl/SSLContextImpl;Ljava/lang/String;ILjava/net/InetAddress;I)V+144
j  sun.security.ssl.SSLSocketFactoryImpl.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+13
j  com.ufclub.daq.qhzx.utils.SSLProtocolSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+15
 .... Опустите код

Эта часть содержит подробную информацию и стек потока, который вызвал фатальную ошибку JVM.

Информация о потоке

Current thread (0x0000000001e94800):  JavaThread "pool-1-thread-2" [_thread_in_native, id=30111, stack(0x00007f3d567e5000,0x00007f3d568e6000)]

• 0x0000000001e94800: ошибка указателя потока
• JavaThread: тип потока, возможные типы включают

1. JavaThread: поток Java
2. VMThread: внутренний поток JVM
3. CompilerThread: используется для вызова JITing, компиляции и выгрузки классов в реальном времени. Обычно jvm запускает несколько потоков для обработки этой части работы, число после имени потока также будет накапливаться, например: CompilerThread1
4. GCTaskThread: поток, выполняющий gc
5. WatcherThread: поток планирования периодических задач JVM, представляет собой одноэлементный объект
6. ConcurrentMarkSweepThread: когда jvm выполняет CMS GC, он создает поток для выполнения GC. Когда поток создается, он создает поток SurrogateLockerThread (SLT для краткости) и запускает его. После запуска SLT он находится в стадии ожидания. Когда CMST запускает сборщик мусора, он отправляет сообщение SLT, чтобы позволить ему получить глобальную блокировку ссылочного объекта уровня Java: Lock

• pool-1-thread-2: имя потока
• _thread_in_native: текущий статус потока. Описание также включает:

1. _thread_in_native: текущее состояние потока, перечисление состояний включает:
2. _thread_uninitialized: поток еще не создан, он появляется только при сбое памяти
3. _thread_new: поток создан, но не запущен
4. _thread_in_native: поток выполняет собственный код, в целом эта ситуация, вероятно, является проблемой с собственным кодом
5. _thread_in_vm: поток выполняет код виртуальной машины
6. _thread_in_Java: поток выполняет интерпретируемый или скомпилированный код Java.
7. _thread_blocked: поток заблокирован
8. … _Trans: заканчивается на _trans, поток находится в промежуточном состоянии для переключения в другое состояние

• id = 30111: идентификатор потока
• stack (0x00007f3d567e5000,0x00007f3d568e6000): интервал стека

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000003

Указывает на непредвиденную информацию о сигнале, которая вызвала завершение работы виртуальной машины.

Top of Stack: (sp=0x00007f3d568e2280)
0x00007f3d568e2280:   b8e4bfb900000800 00007f3d568e3760
0x00007f3d568e2290:   00007f3d568e3758 00007f3d568e377c
0x00007f3d568e22a0:   00007f3d568e3778 6f6e6b6e56a88a58
0x00007f3d568e22b0:   00000100000149a0 7a68710800000000
0x00007f3d568e22c0:   6970067363642d78 6d6f63036e61676e
 .... опущено

Instructions: (pc=0x0000003797807a91)
0x0000003797807a71:   48 89 45 b8 48 8b 4d b8 0f b6 51 03 89 d3 83 e3
0x0000003797807a81:   0f 75 0d 0f b7 49 06 66 c1 c9 08 66 85 c9 75 4f
0x0000003797807a91:   0f b6 48 03 bf 0f 00 00 00 40 20 cf 75 0d 0f b7
0x0000003797807aa1:   70 06 66 c1 ce 08 66 85 f6 75 34 83 e1 0f 83 e2 

Коды операций рядом с программным счетчиком в верхней части стека можно разобрать на инструкции, которые будут выполняться до сбоя системы.

Stack: [0x00007f3d567e5000,0x00007f3d568e6000],  sp=0x00007f3d568e2280,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
C  [libresolv.so.2+0x7fd1]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 15056  java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress; (0 bytes) @ 0x00007f3d7492af8c [0x00007f3d7492af40+0x4c]
J 14966 C1 java.net.InetAddress.getAddressesFromNameService(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (245 bytes) @ 0x00007f3d75466754 [0x00007f3d754662c0+0x494]
J 14291 C2 java.net.InetAddress.getAllByName(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (387 bytes) @ 0x00007f3d7534b718 [0x00007f3d7534ae20+0x8f8]
J 14178 C1 java.net.InetSocketAddress.<init>(Ljava/lang/String;I)V (47 bytes) @ 0x00007f3d752ce0f4 [0x00007f3d752cdec0+0x234]
j  sun.security.ssl.SSLSocketImpl.<init>(Lsun/security/ssl/SSLContextImpl;Ljava/lang/String;ILjava/net/InetAddress;I)V+144
j  sun.security.ssl.SSLSocketFactoryImpl.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+13
j  com.ufclub.daq.qhzx.utils.SSLProtocolSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+15
 .... Опустите код

Информация о стеке потоков. Содержит адрес, вершину стека, счетчик стека и информацию о неиспользуемом стеке потока. Пока что причина проблемы в основном определена.

Информация о потоке

Java Threads: ( => current thread )
  0x00007f3d5d0a0800 JavaThread "logback-8" daemon [_thread_blocked, id=489, stack(0x00007f3d56de7000,0x00007f3d56ee8000)]
  0x00007f3d5d09f800 JavaThread "logback-7" daemon [_thread_blocked, id=30974, stack(0x00007f3d53fc3000,0x00007f3d540c4000)]
  0x00007f3d5c47f800 JavaThread "logback-6" daemon [_thread_blocked, id=25662, stack(0x00007f3d545c9000,0x00007f3d546ca000)]
  0x00007f3d5c2a4000 JavaThread "logback-5" daemon [_thread_blocked, id=20922, stack(0x00007f3d552d2000,0x00007f3d553d3000)]
  0x0000000003291800 JavaThread "logback-4" daemon [_thread_blocked, id=16768, stack(0x00007f3d542c6000,0x00007f3d543c7000)]
  0x0000000002320000 JavaThread "logback-3" daemon [_thread_blocked, id=14730, stack(0x00007f3d54bcd000,0x00007f3d54cce000)]
  0x0000000002d05000 JavaThread "logback-2" daemon [_thread_blocked, id=6569, stack(0x00007f3d549cb000,0x00007f3d54acc000)]

Вся информация о потоках понятна с первого взгляда. _thread_blocked означает блокировку.

Информация о точке безопасности и замке

VM state:not at safepoint (normal execution)

Статус виртуальной машины. Не в безопасной точке означает нормальную работу. Другие состояния:

• в точке безопасности: все потоки заблокированы из-за состояния ожидания виртуальной машины, ожидая завершения операции виртуальной машины;
• синхронизация: специальная операция виртуальной машины, которая требует, чтобы другие потоки в виртуальной машине продолжали ждать.

VM Mutex/Monitor currently owned by a thread: None

Mutex и Monito r виртуальной машины в настоящее время не удерживаются потоком. Mutex — это блокировка внутри виртуальной машины, а Monitor связан с объектами Java.

Информация о куче

Heap:
 PSYoungGen      total 178688K, used 25522K [0x00000000eab00000, 0x00000000f8d80000, 0x0000000100000000)
  eden space 177664K, 13% used [0x00000000eab00000,0x00000000ec343d30,0x00000000f5880000)
  from space 1024K, 65% used [0x00000000f8c80000,0x00000000f8d28d20,0x00000000f8d80000)
  to   space 1024K, 0% used [0x00000000f8b80000,0x00000000f8b80000,0x00000000f8c80000)
 ParOldGen       total 360448K, used 47193K [0x00000000c0000000, 0x00000000d6000000, 0x00000000eab00000)
  object space 360448K, 13% used [0x00000000c0000000,0x00000000c2e16518,0x00000000d6000000)
 Metaspace       used 79300K, capacity 80628K, committed 80936K, reserved 1120256K
  class space    used 9401K, capacity 9645K, committed 9768K, reserved 1048576K

Card table byte_map: [0x00007f3d729f1000,0x00007f3d72bf2000] byte_map_base: 0x00007f3d723f1000

Новое поколение, старое поколение и метапространство понятны с первого взгляда.

Card tableПредставляет карточную таблицу, структуру данных, поддерживаемую jvm, используемую для записи ссылок при изменении объектов, так что при gc можно перемещаться по меньшему количеству таблиц и корней.

Кеш локального кода

CodeCache: size=245760Kb used=41374Kb max_used=41402Kb free=204385Kb
 bounds [0x00007f3d72fb2000, 0x00007f3d75872000, 0x00007f3d81fb2000]
 total_blobs=12767 nmethods=12130 adapters=549
 compilation: enabled

Часть памяти, используемая для компиляции и сохранения собственного кода.

Скомпилировать событие

Compilation events (10 events):
Event: 501041.566 Thread 0x0000000001b6e000 16334       3       sun.security.rsa.RSAKeyFactory::<init> (5 bytes)
Event: 501041.566 Thread 0x0000000001b6e000 nmethod 16334 0x00007f3d74985790 code [0x00007f3d74985900, 0x00007f3d74985b10]
Event: 501041.569 Thread 0x0000000001b6e000 16335       3       sun.security.pkcs.PKCS8Key::<init> (5 bytes)
Event: 501041.570 Thread 0x0000000001b6e000 nmethod 16335 0x00007f3d74736290 code [0x00007f3d74736400, 0x00007f3d747365b0]
Event: 501041.575 Thread 0x0000000001b6e000 16336       3       sun.security.ssl.BaseSSLSocketImpl::<init> (15 bytes)
Event: 501041.576 Thread 0x0000000001b6e000 nmethod 16336 0x00007f3d73f9b450 code [0x00007f3d73f9b5c0, 0x00007f3d73f9b7e8]
Event: 501041.578 Thread 0x0000000001b6e000 16337       3       javax.net.ssl.SSLSocket::<init> (5 bytes)
Event: 501041.580 Thread 0x0000000001b6e000 nmethod 16337 0x00007f3d739c7210 code [0x00007f3d739c7380, 0x00007f3d739c7508]
Event: 501041.582 Thread 0x0000000001b6e000 16338       3       javax.net.ssl.SNIServerName::<init> (66 bytes)
Event: 501041.583 Thread 0x0000000001b6e000 nmethod 16338 0x00007f3d74c15cd0 code [0x00007f3d74c15ea0, 0x00007f3d74c164f8]

Запишите 10 событий компиляции. Информация здесь также подтверждает сделанный выше вывод.

журнал gc

GC Heap History (10 events):
Event: 476166.948 GC heap before
{Heap before GC invocations=149 (full 3):
 PSYoungGen      total 194560K, used 193984K [0x00000000eab00000, 0x00000000f8e80000, 0x0000000100000000)
  eden space 193536K, 100% used [0x00000000eab00000,0x00000000f6800000,0x00000000f6800000)
  from space 1024K, 43% used [0x00000000f8c80000,0x00000000f8cf0000,0x00000000f8d80000)
  to   space 1024K, 0% used [0x00000000f8d80000,0x00000000f8d80000,0x00000000f8e80000)
 ParOldGen       total 360448K, used 47161K [0x00000000c0000000, 0x00000000d6000000, 0x00000000eab00000)
  object space 360448K, 13% used [0x00000000c0000000,0x00000000c2e0e518,0x00000000d6000000)
 Metaspace       used 79243K, capacity 80500K, committed 80680K, reserved 1120256K
  class space    used 9400K, capacity 9645K, committed 9768K, reserved 1048576K
Event: 476166.985 GC heap after
Heap after GC invocations=149 (full 3):
 PSYoungGen      total 190464K, used 448K [0x00000000eab00000, 0x00000000f8e00000, 0x0000000100000000)
  eden space 189952K, 0% used [0x00000000eab00000,0x00000000eab00000,0x00000000f6480000)
  from space 512K, 87% used [0x00000000f8d80000,0x00000000f8df0000,0x00000000f8e00000)
  to   space 1024K, 0% used [0x00000000f8c00000,0x00000000f8c00000,0x00000000f8d00000)
 ParOldGen       total 360448K, used 47161K [0x00000000c0000000, 0x00000000d6000000, 0x00000000eab00000)
  object space 360448K, 13% used [0x00000000c0000000,0x00000000c2e0e518,0x00000000d6000000)
 Metaspace       used 79243K, capacity 80500K, committed 80680K, reserved 1120256K
  class space    used 9400K, capacity 9645K, committed 9768K, reserved 1048576K
}
 ... опущено

Он также записывает 10 сборщиков мусора.

карта памяти jvm

Dynamic libraries:
00400000-00401000 r-xp 00000000 fd:00 2108521                            /usr/java/jdk1.8.0_45/bin/java
00600000-00601000 rw-p 00000000 fd:00 2108521                            /usr/java/jdk1.8.0_45/bin/java
019e9000-04f5e000 rw-p 00000000 00:00 0                                  [heap]
c0000000-d6000000 rw-p 00000000 00:00 0 
d6000000-eab00000 ---p 00000000 00:00 0 
... 
7f3d6df48000-7f3d6df6a000 r--s 0038e000 fd:00 2108900                    /usr/java/jdk1.8.0_45/jre/lib/ext/cldrdata.jar
7f3d6df6a000-7f3d6df73000 r--s 07db3000 fd:00 2374798                    /opt/risk/service/xxx-xxx-container/xxx-xxxx-container.jar
... 

Эта информация представляет собой область списка виртуальной памяти при сбое виртуальной машины. Он может сказать вам, какие библиотеки используются во время сбоя, где они расположены, а также информацию о стеке и странице защиты.

• 00400000-00401000: Область памяти
• r-xp: разрешения, r / w / x / p / s означает чтение / запись / выполнение / частный / общий доступ
• 00000000: смещение внутри файла
• • fd: 00: majorID и minorID расположения файла
• 2108521: Номер Inode
• /usr/java/jdk1.8.0_45/bin/java: расположение файла

Из/opt/risk/service/xxx-xxx-container/xxx-xxxx-container.jarМы можем подтвердить, что с этой банкой возникла проблема.

параметры запуска jvm

VM Arguments:
jvm_args: -Xmx1024M -Xms512M -XX:PermSize=128M -XX:MaxPermSize=256M 
java_command: /opt/risk/service/xxx-xxx-xxx-container/xxx-xxx-xxx-container.jar
java_class_path (initial): /opt/risk/service/xxx-xxx-xxx-container/xxx-xxx-xxx-container.jar
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/usr/java/jdk1.8.0_45
CLASSPATH=.:/usr/java/jdk1.8.0_45/lib/dt.jar:/usr/java/jdk1.8.0_45/lib/tools.jar
PATH=/usr/java/jdk1.8.0_45/bin:/bin:/usr/local/erlang/bin:/usr/local/maven3/bin:/usr/local/git/bin:/usr/java/jdk1.8.0_45/bin:/bin:/usr/local/erlang/bin:/usr/local/maven3/bin:/usr/local/git/bin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/root/bin
SHELL=/bin/bash

Параметры виртуальной машины jvm и переменные среды.

Справка

• Интерпретация журнала фатальных ошибок JVM (hs_err_pid.log)
• Анализ журнала фатальных ошибок JVM (hs_err_pid.log)

Last Updated: 07/04/2022
[Time Required for Reading: 3.5 minutes]

JavaDeployReg.log uses the LOG file extension, which is more specifically known as a Log file. It is classified as a Text (Log) file, created for Java Runtime Environment (JRE) 8 Update 221 by Sun Microsystems.

JavaDeployReg.log was first developed on 10/02/2019 for the Windows 10 Operating System in Java Runtime Environment (JRE) 8 Update 221.

This is the most recent release date from Sun Microsystems, according to our records.

Below, you find comprehensive file information, instructions for simple LOG file troubleshooting, and list of free JavaDeployReg.log downloads for each available file version.

What are JavaDeployReg.log Error Messages?

Most LOG errors are due to missing or corrupt files. Your JavaDeployReg.log file could be missing due to accidental deletion, uninstalled as a shared file of another program (shared with Java Runtime Environment (JRE)), or deleted by a malware infection. Furthermore, JavaDeployReg.log file corruption could be caused from a power outage when loading Java Runtime Environment (JRE), system crash while loading or saving JavaDeployReg.log, bad sectors on your storage media (usually your primary hard drive), or malware infection. Thus, it’s critical to make sure your anti-virus is kept up-to-date and scanning regularly.

How to Fix JavaDeployReg.log Errors in 3 Steps (Time to complete: ~5-15 minutes)

If you’re encountering one of the error messages above, follow these troubleshooting steps to resolve your JavaDeployReg.log issue. These troubleshooting steps are listed in the recommended order of execution.

Step 1: Restore your PC back to the latest restore point, «snapshot», or backup image before error occurred.

Step 2: If recently installed Java Runtime Environment (JRE) (or related software), uninstall then try reinstalling Java Runtime Environment (JRE) software.

Step 3: Perform a Windows Update.

If Those Steps Fail: Download and Replace Your JavaDeployReg.log File (Caution: Advanced)

If none of the previous three troubleshooting steps have resolved your issue, you can try a more aggressive approach (Note: Not recommended for amateur PC users) by downloading and replacing your appropriate JavaDeployReg.log file version. We maintain a comprehensive database of 100% malware-free JavaDeployReg.log files for every applicable version of Java Runtime Environment (JRE). Please follow the steps below to download and properly replace you file:

1. Locate your Windows operating system version in the list of below «Download JavaDeployReg.log Files».
2. Click the appropriate «Download Now» button and download your Windows file version.
3. Copy this file to the appropriate Java Runtime Environment (JRE) folder location:

   Windows 10: C:UsersTesterAppDataLocalTemp

4. Restart your computer.

If this final step has failed and you’re still encountering the error, you’re only remaining option is to do a clean installation of Windows 10.

GEEK TIP : We must emphasize that reinstalling Windows will be a very time-consuming and advanced task to resolve JavaDeployReg.log problems. To avoid data loss, you must be sure that you have backed-up all of your important documents, pictures, software installers, and other personal data before beginning the process. If you are not currently backing up your data, you need to do so immediately.

Download JavaDeployReg.log Files (Malware-Tested 100% Clean)

CAUTION : We strongly advise against downloading and copying JavaDeployReg.log to your appropriate Windows system directory. Sun Microsystems typically does not release Java Runtime Environment (JRE) LOG files for download because they are bundled together inside of a software installer. The installer’s task is to ensure that all correct verifications have been made before installing and placing JavaDeployReg.log and all other LOG files for Java Runtime Environment (JRE). An incorrectly installed LOG file may create system instability and could cause your program or operating system to stop functioning altogether. Proceed with caution.

Files Related to JavaDeployReg.log

LOG Files Related to JavaDeployReg.log

File Name	Description	Software Program (Version)	File Size (bytes)	File Location
SRU.log	Log	Java Runtime Environment (JRE) 8 Update 221	65536	C:WindowsSystem32sru
WindowsUpdate.log	Log	Java Runtime Environment (JRE) 8 Update 221	276	C:Windows
NGenTask.exe.log	Log	Java Runtime Environment (JRE) 8 Update 221	517	C:WindowsSysWOW64configsystemprofileAppDat…
setupact.log	Log	Java Runtime Environment (JRE) 8 Update 221	14557	C:WindowsSystem32SysprepPanther
aria-debug-6872.log	Log	Java Runtime Environment (JRE) 8 Update 221	470	C:UsersTesterAppDataLocalTemp

Other Files Related to JavaDeployReg.log

File Name	Description	Software Program (Version)	File Size (bytes)	File Location
CBS.log	Log	Java Runtime Environment (JRE) 8 Update 221	888703	C:WindowsLogsCBS
setuperr.log	Log	Java Development Kit (32 bit) 8 Update 221	16723	C:WindowsLogsDPX
setupact.log	Log	Java Runtime Environment (JRE) 8 Update 221	14557	C:WindowsSystem32SysprepPanther
SA.DAT	Game Data	NetBeans 9	6	C:WINDOWSTasks
klist.exe	Java(TM) Platform SE binary	Java(TM) Platform SE 8 (8.0.2310.11)	16408	C:Program Files (x86)Javajdk1.8.0_231jrebin

You are downloading trial software. The purchase of a one-year software subscription at the price of $39.95 USD is required to unlock all software features. Subscription auto-renews at the end of the term (Learn more). By clicking the «Start Download» button above and installing «Software», I acknowledge I have read and agree to the Solvusoft End User License Agreement and Privacy Policy.