Can't dump heap on java process
up vote
0
down vote
favorite
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).
java heap-dump jmap
add a comment |
up vote
0
down vote
favorite
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).
java heap-dump jmap
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 8:31
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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).
java heap-dump jmap
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).
java heap-dump jmap
java heap-dump jmap
edited Nov 22 at 16:54
TimWolla
23.6k64676
23.6k64676
asked Aug 15 '10 at 8:23
duduamar
2,17332541
2,17332541
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 8:31
add a comment |
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 8:31
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 8:31
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 8:31
add a comment |
3 Answers
3
active
oldest
votes
up vote
1
down vote
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.
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 9:04
add a comment |
up vote
0
down vote
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.
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… 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
add a comment |
up vote
0
down vote
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.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3486693%2fcant-dump-heap-on-java-process%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
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.
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 9:04
add a comment |
up vote
1
down vote
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.
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 9:04
add a comment |
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Aug 15 '10 at 8:58
Stephen C
511k69560911
511k69560911
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 9:04
add a comment |
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 9:04
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 9:04
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 9:04
add a comment |
up vote
0
down vote
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.
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… 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
add a comment |
up vote
0
down vote
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.
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… 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
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
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.
answered Aug 15 '10 at 8:42
Thorbjørn Ravn Andersen
57k23145288
57k23145288
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… 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
add a comment |
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… 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
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
visualvm works, but didn't give me any useful information. I was looking particularly for a heap dump.
– duduamar
Aug 15 '10 at 9:30
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… it can create a heap dump for a local application.
– Thorbjørn Ravn Andersen
Aug 15 '10 at 10:17
According to download-llnw.oracle.com/javase/6/docs/technotes/guides/… 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
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
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
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
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.
answered Jul 10 '17 at 18:18
Kumar
12011
12011
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3486693%2fcant-dump-heap-on-java-process%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 8:31