Eclipse TPTP to track memory leak?

Hello,
I am writing a rather large program and I am collecting a lot of data. My problem is that I'm running out of heap space. I need to track large amounts of weather data over the course of the year, but I don't think that is the problem. I think I have a memory leak somewhere and I can't find it. I am working in Eclipse and I've heard a bit about the TPTP tools. I was just wondering if anyone could direct me to a tutorial for using these tools or at least give me a general set of instructions? I have everything installed but can't find a good tutorial anywhere.

JProfiler is one such tool.
However, you might try increasing the amonut of memory the heap in java is allowed to use before looking into those tools.
Perhaps your application just uses a lot of memory rather than a memory leak. Search google for 'java xmx' on how to increase heap size.

Similar Messages

  • How to track Memory Leaks in 3.6.8?

    I've been noticing for several updates now that I seem to be getting major memory leaks. Firefox starts off around 1-200,000 K memory usage in task manager, but within a few hours it will be past 800,000 K. Now, the things I've seen so far talk about disabling plugins and all to find the problem, but this doesn't happen immediately, so disabling things one by one isn't very feasible. How can i track the memory leak to a specific plugin, or else make it leak much, much faster so I can do the one by one thing?
    == This happened ==
    Every time Firefox opened
    == A few updates ago

    Well, It just has taken a turn for the worse... In the attached screenshot you can see firefox took 1.123.112kb out of my memory at which point the GUI became unresponsive. This has actually happened before, but not as soon...
    I had 18 tabs open (but at the moment I have all of them opened again after a restart of firefox and it takes 143.988 kb at this very moment, which still is a lot actually). My computer has 4gb RAM-memory of which 46% is in use at the moment according to windows task manager.
    It would be great if the whole tabstructure and maybe the garbage collector for the TraceMonkey javascript engine was reviewed... This might point out where the memory leaks are located.

  • How to track memory leak

    using an n85, i consistantly have problems when i'm in my call log.  i get "log:memory full. close some applications and try again." even though i rebooted and when i check under open apps (by holding down app key), no program is open. i also have 69 megs free in phone memory (per file manager). is there a program that lists what processes are taking up memory (kinda of like MS's windows task manager or linux's TOP command)?

    i did both hard resets-3key+ on button, and also 7380 method, which both work (it asks for country, time, etc), then when i restore, i get same problem. seeing how i can use other programs-web browser, gps programs, etc without any 'memory full' problem, i think it's a problem w/ the memory allocated just to the log program-and i'm running in that limit. also, i use my phone for voip calls, and the phone numbers are longer-in the 'sip:[email protected]' format, and i'm not sure if it has something to do with that. will see if the developer forum has additional info. thanks for your help!

  • Memory Leak when just launched and Idle..  fixes when being used ??  [HELP]

    So I'm in the debugging and testing phase of my app and using this tool for tracking memory leaks ( https://github.com/mrdoob/Hi-ReS-Stats )
    When I launch my app my numbers are
    FPS: 61/60
    MS: 17
    MEM: 3.157
    MAX: 3.157
    Now immediately my memory starts increasing    from  3.157, 3.167, 3.177, 3.187, 3.197 and so on.
    Now if I make any nav selection in my app
    MEM changes back down to about 3.215
    but then it starts its count again   3.215, 3.225,  3.235, 3.445, 3.455
    I don't have any loops happening.
    Has anyone run in to this ?
    I'm almost tempted to force garbage collection every 60 seconds that the app is idle or something.  Not the best way to handle this ..   I just dont know where the leak is happening.
    Any support is appreciated!
    Cheers!

    Hi there - I just had the same query a couple of days ago (http://forums.adobe.com/thread/977174?tstart=30).
    I saw the same symptoms on my app so I built a blank app with just the profiler on stage. I've been monitoring it for a few days now and notice that memory does creep up even when the app is left idle (apart from the profiler) - but ... and this is the important bit ... it does periodically get reduced back to the starting point (when the garbage collector kicks in and memory is released).
    When I was monitoring my app the time through this cycle could be well over 5 mins.
    If you actually use the monitor when putting your app through it's paces you'll see memory being gobbled up more rapidly and hopefully (if you've no leaks) the garbage collection kicking in more regularly and bringing the reported usage back down.

  • Tracking down a memory leak in LV8.2 when you can't use the profiler

    I am working with this large application. I have satisfied myself that it does have a memory leak by watching the Window's Task Manager while using the app.
    My first preference is to use the Profiler. However when I press 'Start' on the profiler, it instantly crashes LV. It does not do this for all VIs. I have tried to find the offending VI as narrowly as possible, but a VI that crashes profiler on one machine doesn't on another, so I gave that path up.
    If someone knows of a thread about the profiler crashing, please point me that way.
    Failing that, what kind of tips are there for tracking this leak down?
    Thanks!

    Hiya,
    Don't know of anything that will crash the profiler right off-hand, but it never struck me as the most... ah, robust bit of code in LV.
    As far as pre-existing tools, you could try the memmon.llb that lives in the National Instruments/<labview>/examples folder.  It should show the memory load of each vi in memory, though it may require a little retooling to get things into a view that you like.
    If you're on Windows, there are a number of tricks you can play with the SysInternals (now Microsoft) tools.  This usually boils down to watching lower level accesses to the operating system for patterns that look suspicious.  Not a high yield path, but occasionally it works.
    For methods, I like divide and conquer.  The more portions you can eliminate as NOT having the problem, the fewer portions of your code you have left to look for problems in.
    Tracking down memory leaks can be very difficult, but most show up in the end.
    Good bug hunting!
    Joe Z.

  • Eclipse plugin Memory Leak

    Hello all,
    I just started using Kodo. Everything works very well and this is a nice
    product. My only problem is that there seems to be a memory leak when
    using the Eclipse plugin. The memory taken by the javaw process in task
    manager grows and grows if I keep using the mapping tool from inside
    eclipse with the kodo buttons on top. When memory usage gets to around
    400mb I restart Eclipse.
    Has anyone else run into this problem? Is there any way around it?
    Thanks in advance,
    Adam.

    Adam-
    We haven't seen any reports of this. Can you describe the actions you
    take with Kodo? Specifically, are there any particular actions that if
    you just repeat over and over, Eclipse runs out of memory?
    Also, what version of Eclipse are you using? Earlier versions has a bug
    with an interaction with ant has a memory leak. See:
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=24448
    In article <cqk2qt$ovn$[email protected]>, Goerge wrote:
    >
    Hello all,
    I just started using Kodo. Everything works very well and this is a nice
    product. My only problem is that there seems to be a memory leak when
    using the Eclipse plugin. The memory taken by the javaw process in task
    manager grows and grows if I keep using the mapping tool from inside
    eclipse with the kodo buttons on top. When memory usage gets to around
    400mb I restart Eclipse.
    Has anyone else run into this problem? Is there any way around it?
    Thanks in advance,
    Adam.
    Marc Prud'hommeaux
    SolarMetric Inc.

  • Memory Leak - macromedia.util.UtilPagedTempBuffer

    Hi,
    I've been trying to track down a slow memory leak on a ColdFusion 8 server for a month, and have stalled a bit.
    I've been through all the usual techniques for debugging memory leaks in coldfusion, without any success, so I started using Java memory Profilers to see what's clogging up the heap.
    I've been using the MAT plugin for eclipse, and it keeps pointing to the macromedia.util.UtilPagedTempBuffer class as the problem. The retained size of each instance isn't too large at about 66k, but thousands of them can build up in a few days, which causes the problem. For some reason, the instances of this class just aren't being released for garbage collection.
    I'm stuck now, as googling this class doesn't give me any further information.
    I would appreciate any information you have on this class, even just knowing the basics of what it does? Any explanation as to why it doesn't clear would help a lot.
    Thanks in advance

    Thanks for the reply.
    There shouldn't be any file uploads going on, so I'm starting to think it could be an sql issue.
    Although googling this class only seemed to bring it up in stack traces, the adjacent stack places seemed to be SQL related classes.
    I'm starting to think that it's either a problem with the SQL drivers or some configuration setting I've used for the datasource.
    I'm using CF8 standard on a 64bit windows vps (iis running in 32bit compatiblity mode). The database is MS SQL 2005, presumably running as a 64bit application.
    Do you think this could be the issue? Is it worth changing the database drivers (and how would I go about this)?

  • Possible Memory Leak, many instances of macromedia.jdbc.oracle.OracleConnection, serviceFactory

    I'm using a plug-in for Eclipse to help identify possible memory leaks however we are having trouble interpreting the results.  The top, and pretty much the only, suspect is this...
    7,874 instances of "macromedia.jdbc.oracle.OracleConnection", loaded by "coldfusion.bootstrap.BootstrapClassLoader @ 0xf935218" occupy 604,781,904 (71.02%) bytes. These instances are referenced from one instance of "java.util.HashMap$Entry[]", loaded by "<system class loader>"
    Any ideas what could cause this many instances?  How do we track this back to a particular cfm or cfc?  Do these number seem high or is that normal?  The system in question normally only has 30-60 concurrent users.
    The one item I'm a little skeptical of is the use of the "coldfusion.server.ServiceFactory" and "coldfusion.sql.QueryTable" objects.  We use them for 1000s of different queries, even queries within large loops.  Could these be the problem?  Each time we need to execute a query we do a createObject for each of these objects, when done we close the connection.  I recently found a similar example where they close the recordSet first and then close the connection, we are not closing the recordSet.  Any help at all is much appreciated.

    It could simply be caused by the obvious: a query or queries making a large number of connections and/or consuming large resources on the Oracle database. Use Eclipse to search your application folder for queries. Can you identify any queries that could be the culprit? Is there a loop containing a method or an instance of a component that queries an Oracle database?
    What's your Coldfusion  version? If you're on CF8 or CF9 then the server monitor (in the Coldfusion Administrator) might tell you the process responsible for the high consumption.

  • T61 with memory leak on XP for driver battc.sys

    Hi
    I have an issue with XP where the battc.sys module that is part of Windows XP and responsible for the kernel side of monitoring the battery status. This module continually leaks memory until I have no more kernel paged resources left and programs start to fail on my laptop.
    I raised a support case for this with Microsoft and after some investigation and upgrading to the latest T61 power drivers that were released a few days ago on the Lenovo site, MS support told me it is a fault of the T61 and that I would need to disable Microsoft APCI support to stop this memory leak from occuring and to take the issue up with Lenovo.
    I have used the verifier tool to confirm that it is the Windows XP SP3 battc.sys memory module leaking.
    I am running the latest T61 drivers and fully patch with MS drivers on SP3.
    As MS have told me it is the fault of the T61 I am posting this issue here.
    Thanks
    Stephen

    It is memory available to the kernelwhich itself does not show under a process in task manager as far as I am aware (unles it is taken account as part of the system process).
    The best way to measure the available kernel memory space available is by using sysinternals procexp.
    You need to download procexp and also install the windows debugging tools from Microsoft. Then in procexp set the "Options > Configure Symbols : Debughlp.dll path" to the new debughlp.dll installed with your debu tools and set the symbols path to srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
    Then you can choose in procexp "View > System Information" and see the used and total paged and non-paged kernel memory space.
    poolmon helps monitor all the symbols that are taking up this memory and verifier lets you drill down to the exact module and the changes in memory for a module that is occuring.
    Here are two really good links on it
    http://blogs.msdn.com/ntdebugging/archive/2006/12/18/Understanding-Pool-Consumption-and-Event-ID_3A0...
    http://blogs.msdn.com/ntdebugging/archive/2008/05/08/tracking-down-mmst-paged-pool-usage.aspx
    In my poolmon i notice that Mmst and battc are taking alot of memory after my computer has been running for some time. Mmst being high is normal but battc should not continually be growing as it is which is why I raised the case to MS but they want verification it is not a Lenovo issue.

  • I am getting a memory leak that sometimes leads to an unresponsive Firefox, but does not crash per se.

    Hello, For the last couple of months, I am having issues with one of my tabs or the program itself causing a memory leak. I was hoping that subsequent releases would fix the problem, but when I downloaded V.11 it did not help.
    I use tab mix plus and at any time, usually have about 25 tabs open. Everything functioned okay for 8 or so months up until recently.
    I am wondering if there is a way to try to track down what is causing the leak. If it is one of my open pages, i will get rid of it. I tried opening one page at a time from scratch, but could not find the issue. .
    I always have flash block enabled to cut down on the website junk.
    using OSX firefox v11.

    Now, I'm not going to say it's an Add-On problem because from the research I've been doing on this problem for the last half hour shows that everyone has DIFFERENT add-ons, but everyone's having the SAME problem....
    So I went through my add-ons and disabled them one by one, and the single add-on that has been giving me grief is the latest WOT add-on. So, I have Firefox 11 (so does my wife) and we both have the WOT add-on. But that's where the similarity ends... I have Windows 7 x64, she has Windows XP x86.... but she doesn't have the memory leak problem.
    What I see is a sawtooth pattern over time. Memory goes up a little over 30+ seconds, then drops down. But over half an hour, the peaks of the sawtooth are larger, and it doesn't drop back down to the same level again - always a little more than before. And before you know it, FF is peaking at 1.5+GB, dropping down to 1.2GB... and FF is running very, very slowly.... excessive disk accesses (paging probably, though I apparently I still have 1.5 to 2.0 GB of free RAM). Killing FF frees it all up, and if I open FF again, it's back to using 250MB of RAM.
    So, it's not the add-ons per se, but how they're interacting with FF (or the other way round).... most likely, it's this plug-in container they created to stop add-ons from taking FF with them when they crashed. Seems to have created more problems than it has solved..... would be great if you could choose not to use it....

  • Memory leak using xslprocessor.valueof in 11.1.0.6.0 - 64bit ??

    My company has made the decision to do all of our internal inter-system communication using XML. Often we may need to transfer thousands of records from one system to another and due to this (and the 32K limit in prior versions) we're implementing it in 11g. Currently we have Oracle 11g Enterprise Edition Release 11.1.0.6.0 on 64 bit Linux.
    This is a completely network/memory setup - the XML data comes in using UTL_HTTP and is stored in a CLOB in memory and then converted to a DOMDocument variable and finally the relevant data is extracted using xslprocessor.valueof calls.
    While this is working fine for smaller datasets, I've discovered that repeated calls with very large documents cause the xslprocessor to run out of memory with the following message:
    ERROR at line 1:
    ORA-04030: out of process memory when trying to allocate 21256 bytes
    (qmxdContextEnc,)
    ORA-06512: at "XDB.DBMS_XSLPROCESSOR", line 1010
    ORA-06512: at "XDB.DBMS_XSLPROCESSOR", line 1036
    ORA-06512: at "XDB.DBMS_XSLPROCESSOR", line 1044
    ORA-06512: at "SCOTT.UTL_INTERFACE_PKG", line 206
    ORA-06512: at line 28
    Elapsed: 00:03:32.45
    SQL>
    From further testing, it appears that the failure occurs after approximately 161,500 calls to xslprocessor.valueof however I'm sure this is dependent on the amount of server memory available (6 GB in my case).
    I expect that we will try and log a TAR on this, but my DBA is on vacation right now. Has anyone else tried calling the xslprocessor 200,000 times in a single session?
    I've tried to make my test code as simple as possible in order to track down the problem. This first block simply iterates through all of our offices asking for all of the employees at that office (there are 140 offices in the table).
    DECLARE
    CURSOR c_offices IS
    SELECT office_id
    FROM offices
    ORDER BY office_id;
    r_offices C_OFFICES%ROWTYPE;
    BEGIN
    OPEN c_offices;
    LOOP
    FETCH c_offices INTO r_offices;
    EXIT WHEN c_offices%NOTFOUND;
    utl_interface_pkg.get_employees(r_offices.office_id);
    END LOOP;
    CLOSE c_offices;
    END;
    Normally I'd be returning a collection of result data from this procedure, however I'm trying to make things as simple as possible and make sure I'm not causing the memory leak myself.
    Below is what makes the SOAP calls (using the widely circulated UTL_SOAP_API) to get our data and then extracts the relevant parts. Each office (call) should return between 200 and 1200 employee records.
    PROCEDURE get_employees (p_office_id IN VARCHAR2)
    l_request utl_soap_api.t_request;
    l_response utl_soap_api.t_response;
    l_data_clob CLOB;
    l_xml_namespace VARCHAR2(100) := 'xmlns="' || G_XMLNS_PREFIX || 'EMP.wsGetEmployees"';
    l_xml_doc xmldom.DOMDocument;
    l_node_list xmldom.DOMNodeList;
    l_node xmldom.DOMNode;
    parser xmlparser.Parser;
    l_emp_id NUMBER;
    l_emp_first_name VARCHAR2(100);
    l_emp_last_name VARCHAR2(100);
    BEGIN
    --Set our authentication information.
    utl_soap_api.set_proxy_authentication(p_username => G_AUTH_USER, p_password => G_AUTH_PASS);
    l_request := utl_soap_api.new_request(p_method => 'wsGetEmployees',
    p_namespace => l_xml_namespace);
    utl_soap_api.add_parameter(p_request => l_request,
    p_name => 'officeId',
    p_type => 'xsd:string',
    p_value => p_office_id);
    l_response := utl_soap_api.invoke(p_request => l_request,
    p_url => G_SOAP_URL,
    p_action => 'wsGetEmployees');
    dbms_lob.createtemporary(l_data_clob, cache=>FALSE);
    l_data_clob := utl_soap_api.get_return_clob_value(p_response => l_response,
    p_name => '*',
    p_namespace => l_xml_namespace);
    l_data_clob := DBMS_XMLGEN.CONVERT(l_data_clob, 1); --Storing in CLOB converted symbols (<">) into escaped values (&lt;, &qt;, &gt;).  We need to CONVERT them back.
    parser := xmlparser.newParser;
    xmlparser.parseClob(parser, l_data_clob);
    dbms_lob.freetemporary(l_data_clob);
    l_xml_doc := xmlparser.getDocument(parser);
    xmlparser.freeparser(parser);
    l_node_list := xslprocessor.selectNodes(xmldom.makeNode(l_xml_doc),'/employees/employee');
    FOR i_emp IN 0 .. (xmldom.getLength(l_node_list) - 1)
    LOOP
    l_node := xmldom.item(l_node_list, i_emp);
    l_emp_id := dbms_xslprocessor.valueOf(l_node, 'EMPLOYEEID');
    l_emp_first_name := dbms_xslprocessor.valueOf(l_node, 'FIRSTNAME');
    l_emp_last_name := dbms_xslprocessor.valueOf(l_node, 'LASTNAME');
    END LOOP;
    xmldom.freeDocument(l_xml_doc);
    END get_employees;
    All of this works just fine for smaller result sets, or fewer iterations (only the first two or three offices). Even up to the point of failure the data is being extracted correctly - it just eventually runs out of memory. Is there any way to free up the xslprocessor? I've even tried issuing DBMS_SESSION.FREE_UNUSED_USER_MEMORY but it makes no difference.

    Replying to both of you -
    Line 206 is the first call to xslprocessor.valueof:
    LINE TEXT
    206 l_emp_id := dbms_xslprocessor.valueOf(l_node, 'EMPLOYEEID');
    This is one function inside of a larger package (the UTL_INTERFACE_PKG). The package is just a grouping of these functions - one for each type of SOAP interface we're using. None of the others exhibited this problem, but then none of them return anywhere near this much data either.
    Here is the contents of V$TEMPORARY_LOBS immediately after the crash:
    SID CACHE_LOBS NOCACHE_LOBS ABSTRACT_LOBS
    132 0 0 0
    148 19 1 0
    SID 132 is a SYS session and SID 148 is mine.
    I've discovered with further testing that if I comment out all of the xslprocessor.valueof calls except for the first one the code will complete successfully. It executes the valueof call 99,463 times. If I then uncomment one of those additional calls, we double the number of executions to a theoretical 198,926 (which is greater than the 161,500 point where it usually crashes) and it runs out of memory again.

  • JBoss EAP 6 On JRockit - Memory Leak

    hello team.
    I have memory leak problem on jboss and jrockit.
    My Environment :
    1. OS :          
    CentOS release 6.4 (Final)
    2. JRockit :     
    java version "1.6.0_45"
         Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
         Oracle JRockit(R) (build R28.2.7-7-155314-1.6.0_45-20130329-0641-linux-x86_64, compiled mode)
    3. Application Server:
    JBoss EAP 6.2.0.GA
    4. Application
    Large EJB Application (100 and more EJB Beans (Stateless, Stateful,  MDB, Timers and so on)
    Everything works fine on older application server versions (4.3 , 4.2)
    But now I have Problem
    Of course I know that problem is new version - and i have discussion on JBoss forums.
    but guys I have question about jrockit with you:
    What is the option "Other" in memory ??
    [jboss@jboss-new bin]$ jrcmd 17114  print_memusage
    17114:
    Total mapped                       8457864KB           (reserved=2983100KB)
    -              Java heap              3145728KB           (reserved=0KB)
    -              GC tables            105232KB         
    -          Thread stacks       46412KB           (#threads=138)
    -          Compiled code       1048576KB           (used=12257KB)
    -               Internal                   1480KB         
    -                     OS       170324KB         
    -                  Other       3639056KB         
    -            Classblocks         10496KB           (malloced=9631KB #28393)
    -        Java class data       289536KB           (malloced=192391KB #133697 in 28393 classes)
    - Native memory tracking     1024KB           (malloced=294KB #10)
    [jboss@jboss-new bin]$
    This size increases every time - and took entire amount of RAM.
    Thank in Advance.
    Regards,
    Paata Lominadze

    Not sure what the 'other' is, but it is probably best shown by using an example. By using displayMap we can display a memory map of various JVM subsystems and libraries that are loaded, including third-party libraries.
    ./jrcmd 4523 print_memusage displayMap
    Total mapped                  3984796KB           (reserved=2978740KB)
    -              Java heap       524288KB           (reserved=0KB)
    -              GC tables        17548KB         
    -          Thread stacks        20276KB           (#threads=39)
    -          Compiled code      1048576KB           (used=14224KB)
    -               Internal         1672KB         
    -                     OS       146924KB         
    -                  Other      2092648KB         
    -            Classblocks         7424KB           (malloced=7381KB #20064)
    -        Java class data       124416KB           (malloced=124411KB #91048 in 20064 classes)
    - Native memory tracking         1024KB           (malloced=118KB #10)
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
        OS                          *java    r x 0x0000000000400000.(     76KB)
        OS                          *java    rw  0x0000000000612000.(      4KB)
        OS                        *[heap]    rw  0x00000000007c1000.(    132KB)
       INT                           Poll    r   0x000000007fffe000 (      4KB)
       INT                         Membar    rw  0x000000007ffff000.(      4KB)
       MSP              Classblocks (1/2)    rw  0x00000000df8c0000 (   6912KB)
       MSP              Classblocks (2/2)    rw  0x00000000dff80000 (    512KB)
      HEAP                      Java heap    rw  0x00000000e0000000.( 524288KB)
        OS                    *ld-2.12.so    r x 0x0000003664400000.(    128KB)
        OS                    *ld-2.12.so    r   0x000000366461f000 (      4KB)
        OS                    *ld-2.12.so    rw  0x0000003664620000 (      4KB)
        OS                   **ld-2.12.so    rw  0x0000003664621000.(      4KB)
       OS           *gconv-modules.cache    r   0x00007f8f2e4a0000 (     28KB)
    THREAD                     Stack 4630    rwx 0x00007f8f2e4a7000 (      8KB)
    THREAD                     Stack 4630        0x00007f8f2e4a9000 (     12KB)
    THREAD                     Stack 4630    rwx 0x00007f8f2e4ac000 (    244KB)
       MSP         Java class data (5/37)    rw  0x00007f8f2e4e9000 (  14336KB)
       MSP         Java class data (9/37)    rw  0x00007f8f2fa40000 (   5888KB)
                                             rw  0x00007f8f30000000 (    188KB)
                                                 0x00007f8f3002f000 (  65348KB)
                                             rw  0x00007f8f34000000 (    132KB)
                                                 0x00007f8f34021000 (  65404KB)
                                             rw  0x00007f8f38000000 (    412KB)
                                                 0x00007f8f38067000.(  65124KB)
       MSP        Java class data (10/37)    rw  0x00007f8f3c034000 (  34048KB)
                                             rw  0x00007f8f3e174000 (   8200KB)
       MSP        Java class data (11/37)    rw  0x00007f8f3e976000 (    256KB)
        OS                     *libhpi.so    rw  0x00007f8fb37fc000 (      8KB)
        OS                    **libhpi.so    rw  0x00007f8fb37fe000 (      4KB)
      CODE                  Compiled code    rwx 0x00007f8fb37ff000 (     64KB)
      CODE                  Compiled code    rwx 0x00007f8fb380f000 (    128KB)
      CODE                  Compiled code    rwx 0x00007f8fb382f000 (     64KB)
      MSP        Java class data (37/37)    rw  0x00007f8ff83a1000 (    512KB)
        GC Modified Union Set (committed)    rw  0x00007f8ff8421000 (    132KB)
        GC                     Card table    rw  0x00007f8ff8442000 (   1024KB)
        GC        Object bits (committed)    rw  0x00007f8ff8542000 (   8196KB)
    Here
    - thread is thread related (such as thread stacks)
    - int, internal use (such as pointer pages)
    - heap, chunk used by JRockit for the Java heap
    - os, mapped directly from the operating system, such as third party DLLs or shared objects
    - msp, memory space. a memory space is a native heap with a specific purpose, for example native memory allocation inside the JVM
    - gc, garbage collection related, for example live bits
    - code, compiled code
    The 'other' memory space looks to me (from the blank entries in the above print-out) like they are a memory pages to are still not used. When the JVM starts it mappes an amount of memory. To my knowledge JRockit uses mmap (mmap(2) - Linux manual page), which creates a new mapping in the virtual address space. JRockit reserves an amount of memory (Java Heap (heap where your object instances go) + its own runtime (all the others)).
    To see where the growth is in the various memory spaces, you can use 'print_memusage baseline', after which you can execute print_memusage again, for example,
    ./jrcmd 4523 print_memusage scale=M
    4523:
    Total mapped                     3896MB      +4MB (reserved=2905MB -3MB)
    -              Java heap          512MB           (reserved=0MB)
    -              GC tables           17MB         
    -          Thread stacks           19MB           (#threads=39)
    -          Compiled code         1024MB           (used=14MB +1MB)
    -               Internal            1MB         
    -                     OS          143MB         
    -                  Other         2043MB         
    -            Classblocks            7MB           (malloced=7MB #20596 +532)
    -        Java class data          126MB      +4MB (malloced=125MB +4MB #93640 +2592 in 20596 classes)
    - Native memory tracking            1MB           (malloced=0MB #20 +10)
    Note the additional column that prints out the difference in memory usage in relation to the baseline. You can also monitor native allocations by using trace_alloc_sites, memory allocations can then be displayed with different levels of detail using the level argument.
    ./jrcmd 4523 print_memusage trace_alloc_sites=true
    4523:
    Total mapped                  3989660KB   +4864KB (reserved=2974732KB -4008KB)
    -              Java heap       524288KB           (reserved=0KB)
    -              GC tables        17548KB         
    -          Thread stacks        20276KB           (#threads=39)
    -          Compiled code      1048576KB           (used=15265KB +1040KB)
    -               Internal         1672KB         
    -                     OS       146924KB         
    -                  Other      2092648KB         
    -            Classblocks         7680KB    +256KB (malloced=7669KB +287KB #20596 +532)
    -        Java class data       129024KB   +4608KB (malloced=128967KB +4555KB #93640 +2592 in 20596 classes)
    - Native memory tracking         1024KB           (malloced=236KB +118KB #20 +10)
    ./jrcmd 4523 print_memusage level=3
    4523:
    Total mapped                  3989660KB   +4864KB (reserved=2974732KB -4008KB)
    -              Java heap       524288KB           (reserved=0KB)
    -              GC tables        17548KB         
    -          Thread stacks        20276KB           (#threads=39)
    -          Compiled code      1048576KB           (used=15265KB +1040KB)
    -               Internal         1672KB         
    -                     OS       146924KB         
    -                  Other      2092648KB         
    -            Classblocks         7680KB    +256KB (malloced=2KB -7379KB #4 -20060) Not fully traced
    -        Java class data       129024KB   +4608KB (malloced=26KB -124385KB #16 -91032 in 20596 classes) Not fully traced.
    - Native memory tracking         1024KB           (malloced=118KB #10) Not fully traced.
         gather_memorymap_database                     memtrace.c: 206         91KB     +91KB (#1 +1)
               gather_memory_usage                  osal_mspace.c:5142          7KB      +7KB (#4 +4)
      msGatherMSpacesUsageDatabase                  osal_mspace.c:6128          2KB      +2KB (#1 +1)
      msGatherMSpacesUsageDatabase                  osal_mspace.c:6134         16KB     +16KB (#1 +1)
    Note this is more on the JVM level, in your case in might be beneficial to investigate what is happening on the java heap. By using print_object_summary you can get insight how memory on the heap is used on a per-class basis. To get to the bottom of where the memory leak is you can use the memory-leak-detector (an example of its use can be found here Middleware Snippets: Fast, Faster, JRockit). You can also obtain a heapdump that can be analyzed by using for example MAT (see for an example here Middleware Snippets: Visualizing Class Loading). To obtain a heapdump you can run the command, for example,
    [weblogic@machine1 bin]$ ./jrcmd 4523 runsystemgc full=true fullcompact=true
    4523:
    [weblogic@machine1 bin]$ ./jrcmd 4523 hprofdump filename=/home/weblogic/dump.hprof
    4523:
    Wrote dump to /home/weblogic/dump.hprof
    Note that this first issues a full GC by using the runsystemgc command.

  • Memory leak in FormatUtils.formatTimeStatus()

    hello smp developers,
    i find memory leak in
    FormatUtils.formatTimeStatus()
    after every call, in memory stay 4 String, 1 Object, 1 Function and 1 Vector.<String>
    after recreate local function to external, memory leak gone
    and maybe performance issue in ScrubBar.as, for scrubBarLiveOnlyTrack and scrubBarLiveOnlyInactiveTrack
    every frame it create 50 BitmapData and 50 Rectangle, even if live track not showing
    after change it on "new Sprite()" in configure function, create 50 BitmapData and 50 Rectangle gone
    all found in last version of smp
    ps bugbase not working anymore http://bugs.adobe.com/jira/browse/ST? I get "PERMISSION VIOLATION"
    thx,
    mike

    thanks Silviu
    i create two bugs
    https://bugbase.adobe.com/index.cfm?event=bug&id=3341143
    https://bugbase.adobe.com/index.cfm?event=bug&id=3341146

  • Memory leak in "Tenured Generation" heap (JVM 1.5)?!

    For about over a year, I'm trying to hunt down the memory leak in our server application. But after all the improvements I've made (especially with 'forgotten' listeners that didn't exist anymore), I'm confident that the application doesn't have a memory leak anymore. At least the new "jconsole.exe" tool of JDK 1.5 shows me a very intersting behaviour:
    Even if the server app is doing nothing than one thread polling a database table for possible new jobs to process, the memory slightly increases over time ... very slightly. It's just like the screenshot at
    http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html#memory
    where you might find a very slight tendency up. I run jconsole the whole day to track the application on a computer where no jobs got processed, so the application only sit there there whole day and just one thread has a loop that polls a database table via JDBC and doesn't get a result. The result is, that the memory chart is like the chart in the screenshot of the link above just with much more jaggies. About every 20 minutes, garbage collection seems to kick in, as the jaggie line drops about several megabytes just to increase again slowly.
    Of course the thread loop creates objects but it doesn't hold any (debugged it several times and it is quite easy code). So this behaviour makes sense. But it doesn't make sense that the memory usage overall slowly increases over many hours (ultimativaly leading to an OutOfmemoryError).
    So far, I still thought, it must be a memory leak in my application. But then, I played with jConsole and noticed this: if I just display the Memory Pool "Eden Space", the jagged line always drops down to the same level, i.e. no memroy leak. The "Survivor Space" is also constant in average (no memory leak). But the "Tenured Generation" line shows this memroy leak behaviour (slowly increases). This space is described as:
    Tenured Generation (heap): pool containing objects that have existed for some time in the survivor space.
    So, I'm not so sure anymore if this memory must be in my application. Unfortunately, jConsole doesn't show some kind of object tree that can be browsed and I would see what kind of object (collection) increase.
    I tried profiling my application, but the profiled app runs so slowly that it would need many days or weeks until it's possible to identify some bad objects.
    Is there another way to identify such memory waisters?

    Write a main() that does the polling in a tight loop 1000 times. Then System.gc(); Thread.sleep(1000); System.exit(). Run the thing with -Xrunhprof. Observe the "live bytes" and "live objs" columns in the generated java.hprof.txt file. Anything that strikes as suspicious? If every polling round leaks one object, there's likely to be 1000 (or N*1000) of something live. Make sure the leak is in the polling routine by running it 1,000,000 rounds and getting an OutOfMemory.

  • Memory leak in a client using EJBs deployed in a Bea Weblogic 10.0.0 cluste

    Hi all,
    We are having a memory leak in a client using stateless EJBs deployed in cluster. The client is a Tomcat 6.0.18 with java 6 but it is reproduced using Tomcat 5 with java 5. The client is calling a Weblogic Server 10.0 making
    calls to an EJB deployed in cluster that has two instances installed in two different machines.
    The client works fine if we shutdown one of the server instances and so when the client is using only one instance.
    Resuming the environment:
    Client Side:
    1 HP-Itanium machine with HP-UX.
    1 Tomcat 6 with java 6 (reproduced with java 5)
    Bea Weblogic client (wlclient.jar) for Weblogic 10.0.0
    Server Side:
    2 HP-Itanium machines with HP-UX
    Bea Weblogic Server 10.0.0 installed in both machines
    An unique domain
    Two Bea instances (one per machines) associated to a Bea Cluster
    EJBs deployed in both instances
    We have monitored the memory consumed in Tomcat and we have noticed that the VM memory PS OLD GEN grows up permanently when we make tests having the two server side Bea Instances up. We have extended
    the memory VM parameters in Tomcat client till 1G and it's only a way to delay the end: the free memory is empty, the GC is not able to free no more byte and the CPU is 100% consumed by the GC work. At the end Tomcat Client
    doesn't accept more http petitions and must be restarted.
    Besides, we have studied the VM memory in Tomcat using jmap and importing it using Eclipse Memory Analyzer. We have seen some strange memory blocks of several Mbytes that are always growing up and that are stored
    under data structures in the package com.sun.corba:
    com.sun.corba.se.impl.legacy.connection.SocketFactoryConnectionImpl (4.5Mb)
    |
    -> com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl
    |
    -> java.util.Hashtable
    |
    -> java.util.Hashtable$Entry
    |
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    Has anybody any idea about this problem?
    Thanks in advance.

    Hi all,
    We are having a memory leak in a client using stateless EJBs deployed in cluster. The client is a Tomcat 6.0.18 with java 6 but it is reproduced using Tomcat 5 with java 5. The client is calling a Weblogic Server 10.0 making
    calls to an EJB deployed in cluster that has two instances installed in two different machines.
    The client works fine if we shutdown one of the server instances and so when the client is using only one instance.
    Resuming the environment:
    Client Side:
    1 HP-Itanium machine with HP-UX.
    1 Tomcat 6 with java 6 (reproduced with java 5)
    Bea Weblogic client (wlclient.jar) for Weblogic 10.0.0
    Server Side:
    2 HP-Itanium machines with HP-UX
    Bea Weblogic Server 10.0.0 installed in both machines
    An unique domain
    Two Bea instances (one per machines) associated to a Bea Cluster
    EJBs deployed in both instances
    We have monitored the memory consumed in Tomcat and we have noticed that the VM memory PS OLD GEN grows up permanently when we make tests having the two server side Bea Instances up. We have extended
    the memory VM parameters in Tomcat client till 1G and it's only a way to delay the end: the free memory is empty, the GC is not able to free no more byte and the CPU is 100% consumed by the GC work. At the end Tomcat Client
    doesn't accept more http petitions and must be restarted.
    Besides, we have studied the VM memory in Tomcat using jmap and importing it using Eclipse Memory Analyzer. We have seen some strange memory blocks of several Mbytes that are always growing up and that are stored
    under data structures in the package com.sun.corba:
    com.sun.corba.se.impl.legacy.connection.SocketFactoryConnectionImpl (4.5Mb)
    |
    -> com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl
    |
    -> java.util.Hashtable
    |
    -> java.util.Hashtable$Entry
    |
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    Has anybody any idea about this problem?
    Thanks in advance.

Maybe you are looking for