Дамп кучи с помощью jmap выдает NullPointerException

Я пытаюсь сделать дамп кучи с помощью jmap, но продолжаю получать NPE. Я использую Oracle Java7 jdk (подробности ниже).

$sudo jmap -F -dump:format=b,file=heap.bin 21966

Attaching to process ID 21966, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01
Attaching to process ID 21966, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01
Dumping heap to /tmp/dumps/2015-02-18T13:24:36Z-heap.bin ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:606)
  at sun.tools.jmap.JMap.runTool(JMap.java:197)
  at sun.tools.jmap.JMap.main(JMap.java:128)
Caused by: java.lang.NullPointerException
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbolID(HeapHprofBinWriter.java:905)
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeFieldDescriptors(HeapHprofBinWriter.java:743)
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClassDumpRecord(HeapHprofBinWriter.java:511)
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter.access$000(HeapHprofBinWriter.java:297)
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter$1.visit(HeapHprofBinWriter.java:446)
  at sun.jvm.hotspot.memory.SystemDictionary$2.visit(SystemDictionary.java:179)
  at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:69)
  at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190)
  at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(SystemDictionary.java:183)
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClassDumpRecords(HeapHprofBinWriter.java:443)
  at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:413)
  at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:56)
  at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
  at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77)


$java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

Кто-нибудь видел это раньше? При поиске в Google выявляется проблема с OpenJDK (https://bugs.openjdk.java.net/browse/JDK-8028623), но я не уверен, что у Oracle JDK такая же проблема.


java jvm jmap
person Rajiv    schedule 18.02.2015    source источник
comment
Вам нужно использовать -F, чтобы взять дамп? Мой опыт показывает, что инструменты Java намного надежнее, если вы можете избежать использования -F.   -  person K Erlandsson    schedule 18.02.2015
comment
Ты прав. Мне не нужна опция -F.   -  person Rajiv    schedule 19.02.2015

Ответы (1)


arrow_upward
4
arrow_downward

Да, вы нашли правильную ссылку на точно такую ​​же проблему.
Она была исправлена ​​в JDK 7u72.

Кстати, -F опции заставляют jmap работать совершенно по-другому.

  • без -F jmap подключается к целевой JVM с помощью механизма динамического подключения и затем просит JVM создать дамп самостоятельно из процесса JVM;
  • с -F jmap использует Serviceability Agent для приостановки целевого процесса JVM и затем удаленно считывает свою память, выполняя всю работу в отдельном процессе. Хотя SA — классный и мощный инструмент, он не очень хорошо поддерживается, чтобы быть на 100% совместимым с последними деталями реализации JVM. Таким образом, это не редкость, чтобы столкнуться с проблемой с SA.
person apangin    schedule 18.02.2015
comment
Мне удалось заставить это работать: 1. Удалив опцию -F. 2. Запуск jmap от имени пользователя, которому принадлежит процесс. 3. Возиться с правами доступа к каталогу, в котором создается файл (например, chmod o+w /tmp/dumps). Большое спасибо! - person Rajiv; 19.02.2015
comment
Единственный вопрос, который у меня есть: при использовании механизма динамического присоединения, предположим, что jvm занят выполнением GC или занят другим образом (у меня превышено пороговое значение GC), будет ли он по-прежнему отвечать на запрос дампа кучи? В этом случае мне придется использовать опцию «-F»? - person Rajiv; 19.02.2015
comment
@Rajiv Да, недостаток Dynamic Attachment заключается в том, что JVM может не отвечать, если она занята длительным сборщиком мусора или чем-то еще. -F как раз для таких ситуаций. В противном случае Dynamic Attach быстрее и надежнее. - person apangin; 19.02.2015