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










share|improve this question
























  • 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















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










share|improve this question
























  • 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













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










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












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.






share|improve this answer





















  • 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


















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.






share|improve this answer





















  • 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


















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.






share|improve this answer





















    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
    });


    }
    });














    draft saved

    draft discarded


















    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.






    share|improve this answer





















    • 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















    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.






    share|improve this answer





















    • 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













    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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


















    • 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












    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.






    share|improve this answer





















    • 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















    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.






    share|improve this answer





















    • 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













    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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


















    • 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










    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.






    share|improve this answer

























      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.






      share|improve this answer























        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jul 10 '17 at 18:18









        Kumar

        12011




        12011






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Trompette piccolo

            Slow SSRS Report in dynamic grouping and multiple parameters

            Simon Yates (cyclisme)