views:

110

answers:

2

Hi 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.(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).

Thanks!

A: 

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
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
duduamar
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
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
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
+1  A: 

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
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