0

I have a java process which I want to debug. The problem with it is that it has too many open connections, so running jmap fails because it can't connect to process. Running jmap -F produces the next error:

Attaching to process ID 1772, please wait...
sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypeEntryTypeNameOffset" in any of the known library names (libjvm.so, libjvm_g.so, gamma_g)
        at sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:388)
        at sun.jvm.hotspot.HotSpotTypeDataBase.getLongValueFromProcess(HotSpotTypeDataBase.java:369)
        at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:102)
        at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:85)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:568)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:494)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:332)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
        at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.tools.jmap.JMap.runTool(JMap.java:179)
        at sun.tools.jmap.JMap.main(JMap.java:110)
Debugger attached successfully.

What can be the problem? Can it be solved without restarting the process (It is possible the bug will disappear after restarting so I want to avoid it).

TimWolla
  • 31,849
  • 8
  • 63
  • 96
duduamar
  • 3,816
  • 7
  • 35
  • 54
  • Some more details: The problem also occurs with other tools like jstack. Java version is 1.6.0.10-64. System is Linux SUSE 10 x86_64 I run the jmap from the same installation of java as that who ran the application, and from the same user. – duduamar Aug 15 '10 at 08:31

3 Answers3

1

What can be the problem? Can it be solved without restarting the process (It is possible the bug will disappear after restarting so I want to avoid it).

At the risk of stating the obvious ...

If you cannot connect with the debugger because too many connections are open, that is probably also at the root of the bug you are trying to find.

Try using an OS-level utility to find out what files / sockets / etc the process currently has open. That you give you some clues to tell you where to start looking. If that's not enough, search through your codebase for all places where files / sockets are opened, and examine them to make sure that they have an enclosing try / finally that will always close the file / socket.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I can see (kind of) what sockets are open and indeed it gives some clues about the problem, but I still wanted the whole picture, maybe it's impossible to do that in this scenario. Thanks for the help. – duduamar Aug 15 '10 at 09:04
0

Can you use visualvm from the Sun 6 JDK to connect? It uses a different method and allows you to learn a lot - which may be enough - but is not a debugger.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump. – duduamar Aug 15 '10 at 09:30
  • According to http://download-llnw.oracle.com/javase/6/docs/technotes/guides/visualvm/applications_local.html it can create a heap dump for a local application. – Thorbjørn Ravn Andersen Aug 15 '10 at 10:17
  • It still fails. Maybe the process is so stuck so this information cannot be retrieved. I'll have to do with the information I can gather. Thanks guys! – duduamar Aug 15 '10 at 18:49
  • I think you are right in assuming it is stuck. A suggestion for later is to have a log mechanism in place so you can at least see the fatalities when then happened. Either in a file or a place accessible from visualvm. – Thorbjørn Ravn Andersen Aug 15 '10 at 19:39
0

For Sun Jvm : You can try new 

HotSpotDiagnostic().dumpHeap("d:\\HeapDump1",true);

If HotSpotDiagnostic class is not visible at compile time,then You can copy the rt.jar which has the HotSpotDiagnosticMXBean.class to a different location. Refer the copied jar in build path using "Add External jar". This allows you to create Object and get the Heap dump.

Kumar
  • 182
  • 13