Как определить, установлен ли OpenJDK с отладочными символами

Question

Я установил openjdk-devel и openjdk-devel-debuginfo одной и той же основной / дополнительной версии для архитектуры в RedHat Linux Server 8+. Я хотел бы убедиться, что в среде выполнения OpenJDK есть символы для отладки. После установки я выполнил следующее:

[root@localhost bin]# objdump --syms /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/jre/bin/java

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/jre/bin/java:     file format elf64-x86-64

SYMBOL TABLE:
0000000000000270 l    d  .interp    0000000000000000              .interp
0000000000000290 l    d  .note.gnu.property 0000000000000000              .note.gnu.property
00000000000002b0 l    d  .note.ABI-tag  0000000000000000              .note.ABI-tag
00000000000002d0 l    d  .note.gnu.build-id 0000000000000000              .note.gnu.build-id
00000000000002f8 l    d  .hash  0000000000000000              .hash
0000000000000348 l    d  .gnu.hash  0000000000000000              .gnu.hash
0000000000000370 l    d  .dynsym    0000000000000000              .dynsym
....
....
....

[root@localhost etc]# file /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/jre/bin/java: 
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=613871d1514ba05fa2914c22c10f1dfe01d3d2e8, not stripped


[root@localhost bin]# objdump --syms /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/bin/java-1.8.0.242.b08-0.el8_1.x86_64.debug

/usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/bin/java-1.8.0.242.b08-0.el8_1.x86_64.debug:     file format elf64-x86-64

SYMBOL TABLE:
no symbols

[root@localhost bin]# file /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/bin/java-1.8.0.242.b08-0.el8_1.x86_64.debug
/usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el8_1.x86_64/bin/java-1.8.0.242.b08-0.el8_1.x86_64.debug: 
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter \004, for GNU/Linux 3.2.0, BuildID[sha1]=613871d1514ba05fa2914c22c10f1dfe01d3d2e8, with debug_info, not stripped

Как видно из приведенного выше, я вижу, что objdump для java распечатывает какую-то таблицу символов, но я читал, что также следует искать .debug* в выводе, чего я не вижу в оставшейся части SYMBOL TABLE (несколько десятков строк опущены в приведенном выше выводе для краткости).

Я вижу, что file для /usr/lib/debug/..../java...debug говорит with debug_info, но мне нужно подтверждение, что в установке Java есть символы.

Answer 1

java исполняемый файл - это просто простая программа запуска . Вы не найдете там символов JVM.

Чтобы узнать, есть ли в JVM символы отладки, проверьте вместо этого libjvm.so:

nm /usr/lib/jvm/jre/lib/amd64/server/libjvm.so

---

Моя конечная цель - загрузить профилировщик mallo c рядом с моим сервером и пытается отследить выделение собственной памяти. В этом случае, если вызовы отслеживаются до JVM, мне нужно знать, какой метод вызывается.

Ну, если бы вы начали с этого вопроса, вы не попал бы в ловушку XY .

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

Я бы предложил попробовать asyn c -profiler для вызовов профиля malloc, mprotect и mmap. Этот инструмент может отображать смешанные трассировки стека Java +. Вот пример использования asyn c -profiler для профилирования собственных распределений. Это видео также демонстрирует, как asyn c -profiler может помочь в поиске утечек собственной памяти.