PDA - Memory Leak LV 8.0.1 PDA using Slide Indicators

I originally encountered this error when, for no obivous reason, my application would crash after a certain amount of time.  I began to write a message on this board and while I was writing it, it occured to me that this crash certainly reaked of a memory leak.  I went back to my application and added in some memory monitoring displays and sure enough there was a leak.  After about 2 hours of removing everything else that I thought could have possibly caused the error, I removed the slide indicators and low and behold ... Memory Leak gone.  The Vi speaks for itself but I would really like some NI feedback on this.  I'm using LV PDA 8.0.1 under WM5.0 on an iPAQ hx2490.  The leak also occurs with a tank indicator, any slide indicator, a control slide changed to an indicator, and a dial indicator.  It does not, however, occur with the Meter indicator or the thermometer indicator.  Thanks in advance for the feedback NI.
If anyone else would like to verify that this is truly the case and I'm not just seeing things that would be great.
Greycat
Attachments:
SlideMemLeak.vi ‏16 KB

Greycat,
You couldn't be more right. I was able to duplicate exactly what you're seeing. There is certainly a memory leak when you have at least a slide indicator wired up on the block diagram. I'm going to file a bug report to R&D. THANK YOU so much for the code you posted that CLEARLY demonstrates the issue. I'm really sorry for the trouble and I very much appreciate the time you took to trouble shoot your code, find the problem, and even explore the problem. We really appreciate your patience.
Chris C
National Instruments
Applications Engineering
Chris Cilino
National Instruments
LabVIEW Product Marketing Manager
Certified LabVIEW Architect

Similar Messages

  • 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 Input Subsystem 10.3.2.798

    See screenshot. After reboot it drops back down to about 50-60MB but after a while it starts climbing again. This is happening on my Classic with 10.3.2.798.
    I have 3 languages enabled on mine, English QWERTY, Chinese Handwriting and Chinese Pinyin and switch between them, mostly in the Browser.
    http://imgur.com/cdYzu5b

    Update: The input peaked at 499.3MB yesterday. The memory leak seems to occur when I use ALT+ENTER to switch input methods. System displays the list of input types, but at the same time sends a "Submit" to the underlying text field and address bar and the search starts with no text, with the input menu still displayed. Then at that point it starts to leak memory. Please look into this. I had my device rebooted countless times within a week and never had this before 10.3.2.

  • Memory leak in Solaris - SunOS 5.7, jre1.3.1

    Hi,
    I hava a java application that spawns about 100 threads. Each thread sends a request to WebLogic server 6.1. We are using Oracle 8.1.7. They are all running in a Sun box, 2 CPUs and 6gig memory.
    JRE = 1.3.1
    SunOS = 5.7
    Weblogic = 6.1
    Oracle = 8.1.7
    (All running on the same box)
    When we start the client application, running top shows that ,
    the client JVM process - uses 40 MB of memory
    WebLogic - uses 250 MB of memory
    But the available memory comes down drastically (almost by 350 MB), and on bringing both the client and weblogic down, we are not able to get this 350 MB back
    Running JProbe, doen not show any memory leak in our application
    we are using the hotspot client version
    -Xms = 128m
    -Xmx = 128m
    Any help is appreciated

    It looks like i am also facing the same problem with my application . If by some chance you were able to solve this problem do send a mail to [email protected] I just posted the question. while searching the web i found your question which looks similar but not answered. Hope you could give me some input
    Thanks

  • Memory leak in OCI while using AQ

    There seems to be a serious memory leak in the OCI driver (9.2.0.1) when using a JAVA client to dequeue a database queue (Advanced Queuing).
    Continuous dequeuing causes the heap memory to increase, and this memory never gets freed which leads me to suspect a memory leak in the OCI components (as the memory allocated for the JVM is constant). The heap memory increases by 3-4 MB after a dequeue of 1000 RAW messages,
    Has anyone come across this problem before and if so are there any solutions? Changing to a thin driver is not a solution for me due to other requirements.
    I'm using using Oracle client v9.2.0.1 libraries running on Solaris 8.
    The source code for my JAVA test client is as below:
    /* JAVA dequeue */
    package com.ubsw.risk.pce.eventqueues.test;
    import oracle.AQ.*;
    import java.sql.*;
    import oracle.jdbc.*;
    public class testRawDequeue {
    public testRawDequeue() {
    public static void main(String[] args) {
    Connection conn = null;
    AQSession aq_sess = null;
    try {
    Class.forName("oracle.jdbc.driver.OracleDriver");
    //Use OCI connection
    conn = DriverManager.getConnection("jdbc:oracle:oci:@DB_NAME.world","user","password");
    conn.setAutoCommit(false);
    Class.forName("oracle.AQ.AQOracleDriver");
    while(true) {
    aq_sess = AQDriverManager.createAQSession(conn);
    runTest(aq_sess);
    aq_sess.close();
    aq_sess = null;
    System.gc();
    } catch (Exception e) {
    e.printStackTrace();
    System.out.println(e.toString());
    try {
    if (aq_sess != null) {
    aq_sess.close();
    if (conn != null) {
    conn.close();
    } catch (SQLException sqle) {
    public static void runTest(AQSession aq_sess) throws AQException, SQLException
    AQQueueTable q_table;
    AQQueue queue;
    AQMessage message;
    AQRawPayload raw_payload;
    AQEnqueueOption enq_option;
    String test_data = "new message";
    AQDequeueOption deq_option;
    byte[] b_array;
    /* Get a handle to a queue - in aquser schema: */
    queue = aq_sess.getQueue ("user", "raw_msg_queue");
    System.out.println("Successful getQueue");
    /* Creating a AQDequeueOption object with default options: */
    deq_option = new AQDequeueOption();
    /* Dequeue a message: */
    message = queue.dequeue(deq_option);
    System.out.println("Successful dequeue");
    /* Retrieve raw data from the message: */
    raw_payload = message.getRawPayload();
    b_array = raw_payload.getBytes();
    System.out.println("bytes:" + b_array.toString());
    queue.close();
    ((AQOracleSession)aq_sess).getDBConnection().commit();

    This sounds very similar to the memory leak I have in Oracle 9i using Pro*C++. Everytime a connect is made memory appears to leak and it only happens in multithreaded mode not default mode. There is a thread about this under the Oracle C++ call interface. Under 9i it appears to leak about 60K per connect rather than 60 bytes.
    Paul

  • JSF: partial page rendering is causing memory leak leading to outofmemory

    JDeveloper 10.1.3.2.0
    JDK: 1.6.0_06
    Operating System: Windows XP.
    I test my application for memory leaks. For that purpose, I use jconsole to monitor java heap space. I have an edit page that has two dependent list components. One displays all countries and the other displays cities of the selected country.
    I noticed java heap space keeps growing as I change country from country list.
    I run garbage collection and memory usage does not go down. If I keep changing the province for 5 minutes, then I hit a java heap space outofmemory exception.
    To narrow down the problem, I removed the second city component and the problem still exists.
    To narrow it down further, I removed autosubmit attribute from the country component and then memory usage stopped increasing as I change country.
    country/city partial page rendering is just an example. I am able to reproduce the same problem on every page where i use partial page rendering. My conclusion is PPR is causing memory leak or at least the autosubmit attribute.
    This is really bad. Anyone out there experienced same issue. Any help/advice is highly appreciated !!
    Thanks
    <af:panelLabelAndMessage
    inlineStyle="font-weight:bold;"
    label="Country:"
    tip=" "
    showRequired="true"
    for="CountryId">
    <af:selectOneChoice id="CountryId"
                   valuePassThru="true"
                   value="#{bindings.CountryId.inputValue}"
                   autoSubmit="true"
                   inlineStyle="width:221px"
                   simple="true">
         <af:forEach var="item"
              items="#{bindings.CountriesListIterator.allRowsInRange}">
         <af:selectItem value="#{item.countryId}"
                   label="#{item.countryName}"/>
         </af:forEach>
    </af:selectOneChoice>
    </af:panelLabelAndMessage>
    <af:panelLabelAndMessage
    inlineStyle="font-weight:bold;"
    label="City:"
    tip=" "
    showRequired="true"
    for="CityId">
    <af:selectOneChoice id="CityId"
                   valuePassThru="true"
                   value="#{bindings.CityId.inputValue}"
                   partialTriggers="CountryId"
                   autoSubmit="true"
                   inlineStyle="width:221px"
                   unselectedLabel="--Select City--"
                   simple="true">
         <f:selectItems value="#{backing_CountryCityBean.citiesSelectItems}"/>
    </af:selectOneChoice>
    </af:panelLabelAndMessage>

    Samsam,
    I haven't seen this problem myself, no.
    To clarify - are you seeing this behaviour when running your app in JDeveloper, or when running in an application server? If in JDeveloper, a copuple of suggestions:
    * (may not matter, but...) It's not supported to run JDev 10g with JDK 6
    * have you tried the [url http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk11.html]memory profiler
    Best,
    John

  • Memory leak in OCI Direct Path sample program in threaded mode

    I have a slightly (okay, more than slightly) modified version of the sample program cdemodp.c, which uses OCI to do a Direct Path load. Since my eventual aim is to make a C++ module that loads a table from a file as part of a multithreaded program, I made the necessary changes so that cdemodp.c would compile with g++ (v3.3.1, on Solaris 2.8), and I put in the following in place of the OCIInitialize() and OCIEnvCreate() calls (since the docs say those are deprecated):
    OCI_CHECK(0, 0, ociret, ctlp, OCIEnvCreate(&ctlp->envhp_ctl, OCI_THREADED, (void *) 0, 0, 0, 0, (size_t) 0, (void **) 0));
    When I compile and run this version of the program using Purify, I get a 60-byte memory leak inside the OCI code (meaning I can't see the source-code line that is causing the leak). I am pretty sure it's not anything in my code (i.e., me failing to free all handles or something) because when I change the above line so that the mode parameter is OCI_DEFAULT and recompile, there is no memory leak. Since this will be part of a threaded application that is always running, it is critical to make sure there are no leaks.
    Purify says that the leaked memory was allocated from:
    malloc [rtlib.o]
    calloc [rtlib.o]
    nlepeinit [nlepe.c]
    nlstdggo [nlstdgo.c]
    nlstdgg [nlstdgo.c]
    nigini1 [nigini.c]
    I am using Oracle 10g (client version 10.1.0).
    Anyone else had this happen?
    Thanks,
    --Tina Mancuso                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

    This sounds very similar to the memory leak I have in Oracle 9i using Pro*C++. Everytime a connect is made memory appears to leak and it only happens in multithreaded mode not default mode. There is a thread about this under the Oracle C++ call interface. Under 9i it appears to leak about 60K per connect rather than 60 bytes.
    Paul

  • Is there a memory leak in IXML library?

    Hi,
    I wonder if there is a memory leak in the IXML library. Using the memory inspector I observed that memory consumed while building a DOM-tree is never released. Is there some special cleanup method I have to call to free all memory consumed by my DOM tree? I tried to explicitly remove the node to free memory, but that seems not to work (look at my example report below).
    Regards,
    Michael
    REPORT  Z_IXML_TEST                                               .
    data:
      lr_ixml type ref to if_ixml,
      lr_dom type ref to if_ixml_document,
      lr_element type ref to if_ixml_element,
      l_rc type i.
    class cl_ixml definition load.
    lr_ixml = cl_ixml=>create( type = 0 ).
    lr_dom = lr_ixml->create_document( ).
    at this point you see 1 string in Memory Inspector after creating a snapshot
    lr_element = lr_dom->create_element( name = 'root' ).
    call method lr_element->set_attribute( name = 'attrName1' value = 'attrValue1' ).
    call method lr_element->set_value( value = 'value1' ).
    call method lr_dom->append_child( new_child = lr_element ).
    at this point you see 5 strings in Memory Inspector after creating a snapshot
    l_rc = lr_dom->remove_child( old_child = lr_element ).
    lr_element->remove_node( ).
    lr_dom->remove_node( ).
    free lr_element.
    free lr_dom.
    free lr_ixml.
    at the latest at this point you would expect 1 string again, but there are still 5!

    Answer in
    SAP Note 1081257 Memory leak in the iXML library 

  • TestStand 3.1 Report Memory Leak

    Hi everyone,
    I been looking at the memory usage of my TestStand code lately.  I noticed I have a memory leak with On The Fly Reporting using XML report file.  I'm currenlty using labview 7.1.1 and TestStand 3.1f for development.   I came about this program from seeing test station go to a snails crawl.  The program starts out around 100MB and will keep growing using up all the systems memory, the largest I seen was 500MB.   What is happening is the testers like to keep the on the fly report screen up during the test  and not view the execusion window.  At the end of each run the program will grow 10MB to 30MB.    I know the problem can be solved by turning off on the fly reporting, but I would like to try find a programing option first.
    I have looked at the other forum entries about:
    Turning off database collection
    Editing  model options : ModelOptions.DiscardUnusedResults = True and Parameters.ModelOptions.NumTestSockets = 1
    Adjusted the array size of the report to 300
    None of the options seem to have worked for me, most the post say move to teststand 3.1 cause it an 3.0 issue.
    I was wondering if there are any other options to try  in teststand, or any way to turn off/close IE to release memory between tests.
    I'm currently running the code on Windows XP SP2 
    IE6/IE7 depending on the test station
    P4 or Centrino  with 512MB to 1GB of ram
    The GUI window is a modifed  example of the basic VI EXE that calls teststand
    The code is installed using labview and Teststand  deployment builders, so the test machine are using runtime labview 7.1.1  and runtime TestStand 3.1
    Thanks to any one who can offer alittle extra help on the topic

    Actually the reports are XML not HTML.
    There are alot of pass steps, usualy after a couple of failed steps, the sequence will terminate.
    The memory leak seem to exaggerated, since the technicians like to view the Reports Tab instead of Execution Tab when running program.  If the operator keeps the view on the execution tab during the program, the report screen is not being updated, so less memory is taken up.  Since the techs like to keep the report screen up during the entire test, the xml file constantly being update and  the program increases +50MB after the first run.   So turning off Reports on the fly, they can not view the report during the test and the memory usuage stays low.
    I do not see a leak at all if I do not click on the reports tab,  and the leak seems to only happen with XML files, TXT and HTML reports do not cause a memory leak, even when viewed on the fly for the entire test.   I wanted to keep XML-expandable cause it easier to see what sequences failed then scanning through the entire report.
    I'm using Test UUT call up the test.    The executable terminated if you press the exit button on the executable.  After test is finished, the standard Pass/Fail comes up then the standard  enter UUT serial number comes up.
    I'm including the reports option INI  I use .
    Thanks for you help in this matter, sorry being little late with replying. 
    Attachments:
    report.ini ‏4 KB

  • Memory leak on latest Adobe Reader 8.1.2 Win XP SP2

    Dear Adobe Developers,
    I have encountered a strange problem. I open a PDF file of size about 16.5 MB, I search trough it and then the memory allocated starts steadily growing until it fills out the entire RAM and the virtual memory as well. Strange thing is this only happens after I perform a search through the file; if I don't do it, all stays within normal. I was wondering if it is not a memory leak of some kind? I use Adobe Reader 8.1.2 on Win XP with Service Pack 2 on Celeron 1.7 GHZ, 256 DDR RAM, 320 GB HDD ect .. Normally the RAM occupied by the OS itself is only about 100 MB so there are ~150MB left free. But they seem not to be enough even when we add to them the virtual memory.
    Greetings,
    Georgi Popov, BG

    >I have more than 700 MB virtual memory.
    That's probably not enough for normal operations. A couple of
    gigabytes is safer.
    There may be a problem, though. This doesn't sound like normal
    behaviour. Acrobat may be cacheing text - does the size stop
    increasing if you search for something, and find it, on the LAST page?
    Aandi Inston

  • CVI dll to read XML file causes memory leak

    Hello,
    I am facing a memory leak issue when I execute a dll created using CVI to read a XML file.
    Each iteration of the step is taking around 200k of memory.
    Short description of the code:
    Basically I am using a function created in CVI to read from an XML file by tag which 2 attributes: command and the response;
    int GetCmdAndRsp(char XML_File[MAX_STR_SIZE], char tag[MAX_STR_SIZE], char Command[MAX_STR_SIZE], char Response[MAX_STR_SIZE], char ErrorDescription[MAX_STR_SIZE]) 
    inputs:  
    - XML_File_path;
    - tagToFind;
    ouputs:
    - Command;
    - Response;
    - Error;
    Example:
    XMLFile:
    <WriteParameter Command="0x9 %i %i %i %i %i" Response = "0x8 V %i %i %i %i"/>
    Execution:
    error = GetCmdAndRsp("c:\\temp\\ACS_Messages.xml" ,"WriteParameter", cmd, rsp, errStr) 
    output:
    error = 0
    cmd = "0x9 %i %i %i %i %i"
    rsp = "0x8 V %i %i %i %i"
    errStr = "Unkown Error"
    Everything is working correctly but I have this memory leak issue. Why am I having such memory consumption?? Is it a TestStand or CVI issue??
    Each iteration I am loading the file, reading the file and discarding the file.
    Attached you can find the CVI project, a TestStand sequence to test (ReadXML_test2.seq) and an example of a XML file I am using.
    Please help me here.
    Thaks in advance.
    Regards,
    Pedro Moreira
    Attachments:
    ReadXML_Prj.zip ‏1826 KB

    Pedro,
    When a TestStand step executes, its result will be stored by TestStand which will be later used for generating reports or logging data into database.
    You are looking at the memory (private bytes) when the sequence file has not finished execution. So, the memory you are looking at, includes the memory used by TestStand to store result of the step. The memory used for storing results will be de-allocated after finishing the sequence file execution.
    Hence, we dont know if there is actual memory leak or not. You should look at the memory, before and after executing sequence file instead of looking in between execution.
    Also, here are some pointers that will be helpful for checking memory leak in an application:
    1. TestStand is based on COM and uses BSTR in many function. BSTR caches the memory and because of the behavior, sometime you might get false notion of having memory leak. Hence, you need to use SetOaNoCache function OR set the OANOCACHE=1 environment variable to disable caching.
    2. Execute the sequence file atleast once before doing the actual memory leak test. The dry run will make sure all static variables are initialized before doing memory leak test.
    3. Make sure that the state of system or application is same when considering the Private bytes. Ex: Lets say ReportViewControl is not visible before you start executing sequence file. Then you note down the private bytes and then execute the sequence file. After finishing execution, make sure you close the ReportViewControl and then note down the private bytes once again to check if memory is leaked or not.
    4. If there exists memory leak as you specified, it is possible that the leak is either in TestStand, or in your code. Make sure that your code doesn't leak by creating a small standalone application (probably a console application) which calls your code.
    Detecting memory leaks in CVI is better explained in
    http://www.ni.com/white-paper/10785/en/
    http://www.ni.com/white-paper/7959/en/
    - Shashidhar

  • Teststand 3.5 Memory Leak Strategies

    I am experiencing a memory leak when running my test seqeunce using TestStand 3.5.  I have read several messages and Knowledgebase entries to try and collect intelligent memory leak strategies.  I have been running Perfmon on my Windows XP PXI controller card to collect data on the Private Bytes for the process SeqEdit.  This shows a memory increase with each test cycle of over 500 KBytes.  I am trying to reduce my huge test sequence file down to determine where the leaks are occuring, but have the following questions in order to more fully understand TestStand memory issues:
    1) I understand each individual step in a sequence can record results if not disabled.  So, if there are thousands of individual steps this could take up quite a lot of memory.  Does TestStand allocate new memory for these step results, or do the results get stored into memory already allocated for TestStand when it is invoked?  By the way, I debug the memory leak issues with reporting disabled.
    2) If the step results are stored in newly allocated memory, at what point does TestStand free up the additional memory it allocated for the step results?  Is it inside the process model?
    3) Is there a way in the sequence editor to turn off Record Results for multiple steps at once, or must they all be turned off individually (soooo time consuming!).
    4) If memory is newly allocated, is there a step I can execute to force memory to be freed up?
    Ideally, I should be able to start at a certain memory level, execute one test cycle (which has many memory allocations and de-allocations), and at the start of the second test cycle be at the same memory level that was present at the start of the first test cycle.  I actually focus my attention on the second test cycle vs. the third, fourth, ... since the first test cycle can load DLLs for the first time and will affect memory size.
    Any information on the above questions will be greatly appreciated.
    Ron

    Ron,
    What I meant by "default" was just when report generation is turned on and On-The-Fly Reporting is off. The memory used by the results array is released once the scope of the results is lost. In other words, when your sequence is done and ends, the memory is freed. When you use Test UUTs instead of Single Pass, the memory is not freed until the testing is "stopped" instead of choosing to test the next UUT. This does not mean that more and more memory is used for each pass. If you look at the process model for Test UUTs entry point, there are a few steps that clear the results container. That means the memory is still allocated, it just gets cleared and replaced with the new results.
    You keep referring to this as a "memory leak" when it actually is more along the lines of just getting more and more values to be stored into memory instead of a "leak." Something you might check to see is if you are storing numbers in huge arrays, which will also take large chunks of memory. You shouldn't be seeing a memory problem with just a couple thousand steps. I have seen sequence files with over 10,000 steps run before. One other thing you might consider is if you use On-The-Fly Reporting, you will see a slow of execution time.

  • Finding Memory leaks in C using Visual Studio 2013

    I am using Visual Studio 2013, and taking a course in C programming and we started
    talking about memory bugs detaction, in particular memory leaks, and how to detect them using Valgrind on Linux.
    I want to know if there is a way to detect such memory leaks using VS 2013. I tried searching online but it just leads to lots of articles and blogs and msdn posts and blogs with lots of words like dump files, and analyzing them, etc which is weird
    because:
    1) It sounds so complex, convoluted and unintuitive it is actually hard to comprehend it.
    2) The main reason this is weird is due to the fact that VS is the most advanced IDE around and Microsoft spends so much money on in, yet from what I have read it seems that there is no simple way to use VS to detect memory leaks
    - certainly no way that's as simple as Valgrind where I only have to compile the program and run the command valgrind -leaks-check=yes ProgramName
    and it simply prints to me all location it thinks there is a memory leak and describes the error (like not freeing memory after allocating it with malloc hence having "dead" memory after the program finishes, or accessing memory that's out of
    the array bounds)                                                                                                                                                               
    So my question is how to use VS 2013 in order to achieve the same results and to find out First in high level if there are memory leaks in the program, and Second - to detect in a simple manner where those leaks are- preferably without involving dump files
    (not that I know how to use them anyway in VS).

    Hi MicrosoftLaw,
    Thanks for your post.
    Based on your issue, if you want to check if there are memory leaks in the C program from this VS2013. I suggest you could try to find Memory Leaks Using the CRT Library, for more information:
    https://msdn.microsoft.com/en-us/library/x98tx3cf.aspx?f=255&MSPPError=-2147217396
    In addition, I find a similar thread about this issue, please you refer the Dusty's suggestion to check this issue.
    http://stackoverflow.com/questions/45627/how-do-you-detect-avoid-memory-leaks-in-your-unmanaged-code
    I did some research about this issue, I found that the Visual Leak Detector extension tool is a free, robust, open-source memory leak detection system for Visual C++. So if possible, I suggest you could try to use the Visual Leak Detector extension
    tool to find the memory leak for Visual C/ C++ program.
    https://visualstudiogallery.msdn.microsoft.com/7c40a5d8-dd35-4019-a2af-cb1403f5939c
    However, if you have any issue about how to use this Visual Leak Detector extension tool to find the memory leak for C program. I suggest you could directly to write a review to this REVIEW tab in Visual Leak Detector site.
    Best Regards,
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click
    HERE to participate the survey.

  • Wpg_docload.download_file slow (or has a memory leak)

    Hi, (Maybe this should be in the pl/sql forum, but since this is so much used in Apex and I ran into this problem there, I decided to post it here).
    There seems to be a memory leak or some other issue with using wpg_docload.download_file
    I have a couple of pages that show many images (50+, icon sized) . And usually a few days after restarting the Oracle http server, I see the image rendering becoming extremely slow (and usually most images timing out.)
    So in all my procedures using :
    wpg_docload.download_file ( lob_loc );
    I switched it out for :
    declare
    buffer raw ( 32000 );
    buffer_size integer := 32000;
    offset integer := 1;
    begin
    while offset < v_length loop
    dbms_lob.read ( lob_loc, buffer_size, offset, buffer );
    htp.prn ( utl_raw.cast_to_varchar2 ( buffer ) );
    offset := offset + buffer_size;
    end loop;
    end;
    And the speed increase in image loading was phenomenal, I am looking at over 10x speed recieving the image data from the webserver.
    Is there a known bug with wpg_docload.download_file in 10.2.0.2?
    But anyways, if anybody else is running into this slowness, then by all means, try out this workaround.
    Regards
    Oli
    edit:
    There seems to be one other thing that matters in the resulting speed of the image retrieval. I used mod_rewrite to make the images look like /icon/1235.jpg
    and after further testing, this seems to be the catalyst for image retrieval. Not the wpg_docload.download_file
    Message was edited by:
    Oli

    Oli,
    Image retrieval for something.jpg is faster then proc?id=1234That fits in with my theory, browsers often will not rely on a cached version for a URL that contains a parameter (after all, how would the browser know whether the URL is going to return the same data or not even if the parameter is the same?). When you request a particular file (i.e. something.jpg then the browser can use the cache since you have requested a particular file, as opposed to calling a 'procedure/function'.
    This is definetly a browser issue, and it has nothing to do with cacheYou browser has a cache and can use it if it wishes to, so I would still suspect it is related to caching (or lack of caching).
    I would suggest producing the smallest possible test case you can so that the behaviour you describe can be demonstrated.

  • Firefox 4.0b13pre (2011-03-11) on Linux appears to have a memory leak.

    FireFox with 12 tabs open (cnn, msnbc, the.register.co.uk, slashdot, biowar, infoworld, facebook, ebaumsworld, chase online, housereparitalk, meritline, and chicagobusiness) has a memory leak and, before a restart, had used almost 3GB of resident memory. The CPU utilization (4 cores) had gone up to almost 7. Unfortunately, I'll have to go back to Chrome until this bug is fixed as I can't have this affecting my machine like this.

    It would be helpful if Mozilla could provide a memory profiling tool that would help us civilians track down memory problems either in the core products or in extensions. The suggestions to create new profiles, re-add extensions, and do A/B (C/D/E) testing along the way, while accurate, aren't practical when we discover that FF 4 on Win 7 is using north of 1GB of memory.

Maybe you are looking for