Memory Leak in PDA Example App.

I am running the Read Dig Port.VI example that is located: C:\Program Files\National Instruments\LabVIEW 8.2\examples\daqmxbase\PDA\Dio on my PDA (HP iPAQ 2790b) with NI CF 6004 DAQ card. When I check the program memory on my PDA, I see a leak of .01MB about every 5 seconds. Anyone else notice this?
Using:
LabVIEW 8.2
PDA Module 8.2
DAQmx Base 2.10
(I was seeing a .01MB leak every second when I was running my own application, so I switched to the example given by NI to see if that was causing the same issue)
Thanks,
Vickie

Hi,
I have been using
Labview 8.2,
Labview PDA module 8.2 and
NIDAQmxbase 2.1 on a
HP iPAQ hx4700 with a
CF-6004 DAq card
,and I think I have similar problems.
I made a PDA application that aquire continiously 200 samples/second on 4 channels. The DAQ task is configured to get 400 samples (2 seconds of data) each itteration. That should be 3.2KBytes every 2 seconds, but I'm loosing about 18KB every second untill my application crashes.
I tried new DAQmx versions, but that only made things worse.
I would be very interested in discussing the PDA module with anybody who's got some experince. You can allways email me: tschrama-at-fsw.leidenuniv.nl
Regards,
Thijs Schrama

Similar Messages

Memory leak issue in iPhone app

We developed a little program to display PDF's on the iPhone, but it's crashing after scrolling through xx number of pages with low memory error. The app runs fine in the simulator but crashes on the original iphone. I ran the memory leak debugger tool from xcode and got the following:
http://picasaweb.google.com/momopi/MiscCollection#5384555524546579922
(click on magnify glass tool to zoom in)
Weird part is when I run the same on iphone simulator I only get 2 small memory leak warnings (128 bytes each), but on the iphone I get a lot more warnings and it crashes.
Has anyone seen anything like this?

Perhaps you don't have any meaningful leaks. Your program could simply consume too much memory. It has been many years since keeping a small memory footprint was important. Now that Apple has thrown embedded programming to the masses, everyone has forgotten about that.

Fixing Memory Leaks in AIR App?

Hi Friends,
I'm been facing this memory leaks issue in our app and this has taken enough of our time and resources and we are not being able to find a solution for it.
I have identified the problem in the module where we primarily need memory related fixes which is - We are setting Repeater's recycleChildren() property to true/false based upon certain conditions which we cant change. Now when this property is set to false Repeater is supposed to be removing its last created objects from memory and creating fresh ones. In our case repeater is unable to delete those. When I managed to get their instances (using createdChildren()) and freed them in code I called System.gc() for releasing the memory back to OS. Now what is happening is that this approach works fine when I run the app from code but when I create its installer (from Installsheild) and formally out in on machines it does not work. I came to know the reason from following blogs:
http://jvalentino.blogspot.com/2009/05/flex-memory-issue-3-garbage-collection.html
http://gskinner.com/blog/archives/2006/06/as3_resource_ma.html
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/System.htm l#gc()
http://stackoverflow.com/questions/192373/force-garbage-collection-in-as3
http://gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html
Guys, can anyone of you suggest what should I do here? This has become a delivery bottleneck and we need to give a fix where the memroy is released periodically and efficiently so that the end user's system does not hang.
Please help.
Shubhra

Are you sure it doesn't ? Maybe flash does release memory but the OS leaves it assigned as described in the below comment from http://www.mikechambers.com/blog/2008/08/06/what-are-your-biggest-issues-with-adobe-air/co mment-page-3/#comment-26330
"I just finished doing more experiments, I looks like the AIR app does free the memory, but the OS leaves it assignned to the app process, until other apps requiere that memory. So, looks like it is a natural behaviour and the memory leak is not as terrible as I thougth."

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.

BUG: Apex4/Anychart5 - memory leak?

We are running into a pretty serious problem with resources. It seems that there is some kind of interaction between Apex and Anychart5 that is causing a pretty serious memory leak. For example, in one dashboard I am building, I have 9 charts on a page. When I click through a chart to a second page, I have three charts and an Interactive report.
None of the sql is really all that complex. But I will include one of the queries singled out by one of our DBAs as being involved in consuming over 20 GB of data (values slightly modified for security). The query:
SELECT CASE
WHEN quarter = 'Q1'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,1:'
WHEN quarter = 'Q2'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,2:'
WHEN quarter = 'Q3'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,3:'
WHEN quarter = 'Q4'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,4:'
END
link,
quarter label,
so_ext_price Sales_2009
FROM ( SELECT SUM (v.so_ext_price) so_ext_price,
('Q' || TO_CHAR (v.cal_qtr_num)) quarter
FROM owner.materialized_view_mv@db_link_name v
WHERE v.cal_year = TO_CHAR (2009)
AND v.account_number IN
(SELECT *
FROM TABLE(user_pkg.get_customer_numbers (
'APP_USER',
'USER_PROPERTY',
'CUSTOMER_NAME'
-- THE ABOVE SUBQUERY SELECTS FROM A PIPELINE FUNCTION TO RETURN A LIST OF STRINGS
GROUP BY v.cal_qtr_num
ORDER BY v.cal_qtr_num)
As you would expect, this query returns 4 records reflecting sales by quarter. The query takes about four seconds to run. Explain plan cost is just under 14K. The pipeline function literally returns a single column of about six values using a simple select distinct where the parameters passed are filters in the where clause. The pipeline function returns in approximately 1 second. The largest result set it ever returns is six rows. The pipeline function is innocuous on its own but I am suspicious that it may be where we're running into issues. We weren't seeing these problems (or at least they weren't as noticeable) until we needed to use pipline functions. 'Don't use pipeline functions' is not an acceptable work around in our case. While I can figure out a way around it in the charts by returning SQL from a function, I cannot do so in the interactive reports.
What our DBAs found is that the code pasted below is what was sucking down 22 GB of ram, then after clicking through to the second page the same code (for a different chart query) was consuming 17 GB of ram almost depleting our 48 GB of ram on our server in less than ten minutes. I disabled the chart running each 'offending' query and we had the same results with a different chart but the same underlying code below.
I don't know where in Apex this lives but it's the killer. Can I get some feedback? Anyone else having similar issues?
declare
rc__ number;
simple_list__ owa_util.vc_arr;
complex_list__ owa_util.vc_arr;
begin
owa.init_cgi_env(:n__,:nm__,:v__);
htp.HTBUF_LEN := 63;
null;
null;
simple_list__(1) := 'sys.%';
simple_list__(2) := 'dbms\_%';
simple_list__(3) := 'utl\_%';
simple_list__(4) := 'owa\_%';
simple_list__(5) := 'owa.%';
simple_list__(6) := 'htp.%';
simple_list__(7) := 'htf.%';
simple_list__(8) := 'wpg_docload.%';
if ((wwv_flow_epg_include_modules.authorize('apex_util.flash') = false) or (owa_match.match_pattern(p_string =>
'apex_util.flash'
/* */,p_simple_pattern =>
simple_list__
,p_complex_pattern =>
complex_list__
,p_use_special_chars =>
false)))
then
rc__ := 2;
else
null;
null;
apex_util.flash(p=>:p,XMLCallDate=>:XMLCallDate);
if (wpg_docload.is_file_download) then
rc__ := 1;
wpg_docload.get_download_file(:doc_info);
null;
null;
null;
commit;
else
rc__ := 0;
null;
null;
null;
commit;
owa.get_page(:data__,:ndata__);
end if;
end if;
If we are barking up the wrong tree, I'd be VERY happy. I'd rather it was something I could fix.
Edited by: WannaRock on Aug 24, 2010 9:53 AM

Thanks for looking at this post. We have resolved the issue for ourselves by working with our DBAs to narrow down where the problem actually started. We found that the particular SQL we were looking at was not the issue. In a chart on a subsequent page (via a click through), we were actually running into where apex was starting to consuming memory but we were catching it later.
What we found was that when we had a chart query that was SQL containing a pipeline function, the memory usage went up. And within 10 minutes, the server would crawl to a halt. To release the memory, the DBAs would have to bounce the Apex instance. When I changed the query to be a function returning SQL, the problem stopped. I don't know what the correlation was between SQL and moving to a PL/SQL function returning SQL.
I am not even 100% positive of the pipeline function being the cause. I only know that this started happening about the same time as when I implemented the pipeline function. I understand you are leery of a one-second function/query running up that kind of utilization. No one here believed me either (including me really). We figured it HAD to be a coincidence. But once I changed the query from SQL to a function returning PL/SQL, our problem went away.
Thanks to all who looked at and thought about this.
Walter

Memory Leak when running Contacts

I am having a big memory leak when running the app Contacts on a MB Air. It gobbles up 2 GB of ram in just a few minutes forcing a reboot. I have re-installed Mountain Lion 10.8.2 and it still leaks memory. Watching Activity Monitor shows the rapid increase in Ram being gobbled up by Contacts. Used Mackeeper to clear cache as well as ran Cocktail, all to no avail. Any tips would be greatly appreciated.

The size of oracle.exe is not an indication of how the Java VM GC works; so you are not comparing apples to apples. It'll be too long to explain here but in my upcoming book (see hereafter), I gave a detailled explanation of the various memory areas the Java VM uses and how these are GCed and also how you can meausre their size (not all, though).
In short you want to use OracleRuntime methods such as
OracleRuntime.getSessionSize(); --> get he current size of Sessionspace
OracleRuntime.getNewspaceSize(); --> get he current size of Newspace
there are other memory areas described in the book
http://www.oracle.com/technology/pub/articles/mensah_dws.html
http://www.elsevier.com/wps/find/bookdescription.cws_home/706089/description#description
Sample chapter: http://www.oracle.com/technology/books/pdfs/mensah_ch1.pdf
Kuassi

Memory leak when refreshing table models

Hi,
I have a memory leak in a GUI app, and i have traced the problem down to some JTables I have which display data from a database (I used Netbeans profiler to look at the number of objects created for different classes, and there are a large number of classes like com.mysql.jdbc.ResultSet, com.mysql.jdbc.Statement, com.mysql.jdbc.Field[] accumulating, aswell as lots of byte[] and char[] arrays). The allocation stack traces for these objects seem to point to my table models where I do a lot of database lookups to create the model.
Every time I am refreshing the tables, the Heap Space increases by a few MegaBytes, and a load of objects get created and retained. After refreshing the tables a number of times, the heap eventually gets filled and I get OutOfMemory error.
The problem is I don't understand how this is happening - when the tables are refreshed, the code I use is something like this:
setModel(new MyTableModel());
So theoretically each time I refresh, the old model should be garbage collected (because setting the new model means there are no references to the old model), but I get the feeling that all the models are accumulating in the heap and not being collected. I dont understand why this could be - I was wondering if anyone had any ideas? (PS My table models dont use any static fields)
Cheers,
james

Hi JacobsB,
The reason I'm setting new models (which I dont normally do) is that each time the table is refreshed, the number and type of columns may change. Since altering the column model is quite complicated (there is no convenient removeColumn() method of any of the standard model classes) and involves messing around with the column model, which ends up screwing up the whole model (e.g. column renderers, column count, column class etc.) I decided it was actually easier to just create a new model instead! Is there a way to alter the column structure another way?
later,
James

ListOfValues Cancel button creates memory leak

I believe one nuance of the listOfValues element (in an LOV page) gives rise to a memory leak. The examples and listOfValues documentation shows storing data needed by listOfValues events in the session. This is all fine and good if the user clicks on the "Select" button, as you get both a lovSelect and lovUpdate event to work with and clean out session data. But in the case of a user clicking the "Cancel" button, no event is fired, nor is a forward to another DataAction done. The window is simply closed. This strands all the data for the LOV (which could be quite sizable) in the user's session. You can't send this data on the request, because the LOV data must exist across several requests.
Am I completely missing something? How does one clean out a user's session when the Cancel button is clicked on a listOfValues component?
Brad

I am using JDeveloper 9.0.5.2. The restrictions of the project prevent using a newer version of JDeveloper. I am using ADF/Struts, and pure UIX (no JSPS).
The functionality I am speaking of is the standard behavior of the <listOfValues> component (lov for short). The lov component generates events for various behaviors (lovFilter, lovUpdate, loveSelect, etc.). It also completely encapsulates the Cancel and Select buttons, so you have no direct access to those. In order to manage an lov web page (presumably launched from an <lovInput> component on a previous page), the events need access to a certain collection of data (data for the table, max size, starting row, selection, validity, etc.). Because use of the lov page will result in potentially multiple submits, the request is not a good place to store this data, as the data needs to persist for the life of the lov page.
If you look at some of the lovInput/listOfValues examples on the OTN, you'll see that this data is persisted in the user's session. In and of itself, this is fine.
The problem is introduced by the fact that the lov's Cancel button (or window close) does not generate any events, and you don't have direct access to those controls to add an event of your own. When the cancel button is clicked, the window just closes, and in the words of the lov documentation "no other events occur."
This is very problematic -- your session is still stuffed full of data to support the lov. I am looking for a way to remove that data.
Frank -- in your post, you say:
"why can't you add an event to clean the session from the data?"
If you know how to add such an event -- one that fires when the Cancel button is clicked, please enlighten me. I would greatly appreciate it!
Thanks,
Brad

Memory Leak in Preview.app when switching Display Profiles

I found a weird memory leak in Max OS X Preview.app, which manifests itself when Display profiles (color calbration) is change. I wonder if anyone else can reproduce my experience.
1. Open up "System Preferences" -> "Displays", switch to the "Color" tab. You'll need at least 2 available profiles in the list. (If you only have 1, you can create another using "Calibrate..." button to launch Display Calibration Assistant.
2. Open an image file in Preview.app. The larger, the better. Zoom in full size to maximize the effect of the bug. I repro'ed easily with this image: http://www.donporter.net/NewSchool/Color/Examples/Printer%20Test%20file.jpg
3. Open up "Activity Monitor.app", and click on Preview to highlight it, so you can watch its memory usage.
4. Switch back to "Diplays" Preference Pane. Using the arrow keys, toggle up and down between two different Display profiles.
4a. At the same time, watch Preview's "Real Mem" in Activity Monitor, as well as the total "Active" memory.
5. Each time you switch profiles, Preview consumes more Active/Real memory, about 25MB per switch in my case. This continues until all physical memory is consumed, and then (I presume) starts swapping virtual memory to disk.
6. Bring Preview to foreground, and all the profile-induced memory usage is freed.
Weird, wild stuff.

Could it be possible that this is just the OS holding the memory for the app until another process requires it? Do you find that the memory increase eventually causes the app to become unstable?
It might be best to open a new bug report on this over at bugbase.adobe.com. When adding the bug, please include any source code, project or installer that will help us reproduce the issue internally. If you'd like to keep your code private, feel free to email it directly to [email protected] Once entered, please post back with the URL so that others effected can add their comments and votes.
Thanks,
Chris

App-V 5.0 memory leak problem & slow program launch

App-V 5 clients with most recent updates have a memory leak problem. Windows 7 64bit workstations with 8GB of memory will be useless within couple of days because memory has run out. Terminating App-V client process will free the memory, but system starts
to consume it again after that. All hotfixes (up to 5) have been installed.
Another problem is that launching some large (locally cached) programs, for example SolidWorks, takes many minutes for a program to start. With 4.6 there wasn't any performance issues.
Any suggestions?

I saw the exact same issue with slow load times and 50% utilization by AppVClient.exe during that time.
AppV 5 first launch application performance
AppV 5 - Measuring RegistryStaging load times
The issue, specifically, is the amount of time the application takes to stage the registry is what causes the slow load and 50% CPU utilization. I've written a script that stages the registry on your behalf that we use on server startup, after all
the packages are loaded.
Original Thread on MS forums:
https://social.technet.microsoft.com/Forums/en-US/44944302-d8f3-4df1-b104-9c63345f88e0/poor-first-launch-performance-with-appv-5?forum=mdopappv

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

Image Memory Leaks in AIR app

We are implementing an AIR application that loads thumbnails
from the hard drive and uploads them to a remote server.
When bringing in large images, for example, when importing
five 2MB files into Image objects:
Flex reports that it is using 55MB
Windows reports using 220 Meg (viewing memory usage of
adl.exe in task manager)
After deletion of these image objects, the memory stays
allocated!! It is released when the application is closed.
Two issues I see:
1. Huge memory usage for image objects (I understand that JPG
files are exploded into BMPs). It limits our ability to load 10's
or 100's of images.
2. Bad Memory leak
OTHER THINGS WE TRIED:
1. Displaying images as inline html IMG tags.. Same memory
usage!
2. Taking a snapshot of the image and displaying that.
Problem, used way to much CPU
I hope these issues will be fixed before release time or we
are hosed.
PLATFORM: Windows XP Professional, service pack 2

Hi
Have you tried the FB3 profiler to investigate why memory is
not getting deallocated?
You can use the loitering objects panel to track the back
references for the objects in memory. If you find that image object
is not being referenced by anything else. Can you file a bug at
http://bugs.adobe.com/flex
with a small test case.
Also as you know that jpg will be translated into bitmap. The
amount of memory required will be determined by the pixels in the
image. Each pixel will be 4K
Thanks,
Gaurav Jain
Flex SDK Team

JSF (RI) app hot-deploy memory leak

I have a standard JSF (RI) based web app that appears to be working just fine in terms of functionality. However, I believe that there is a memory leak associated with the sort of frequent hot-deploy cycles that are typical during a normal development cycle. I have been monitoring the app via the jvmstat 3.0 tools and have witnessed NO memory growth in the young or old generation areas - regardless of useage pattern. All of the growth seems to happen in the perm area of memory and be directly coincidental with the occurence of a deploy. Eventually, continued hot-deply cycles will result in an OutOfMemory error on the container - please note that continued and extensive use of the app WITHOUT the aforementioned hot-deploys does NOT result in the OutOfMemory error.
From my research so far, I have discovered the following thread:
http://forum.hibernate.org/viewtopic.php?t=935948&postdays=0&postorder=asc&start=75
It refers to a similar problem with hiberate (which I am NOT using) as well as a commons-logging and several others. From the looks of it, I strongly suspect that there may be an issue with JSF when it's implementation is bundled inside the WEB-INF/lib dir - i.e. inside the specific web app's ClassLoader.
Based on the above, I have implemented a SessionContextListener that invokes the org.apache.commons.logging.LogFactory.release() inside the contextDestroyed( ServletContextEvent e ) method. This does appear to free up some perm memory but there is still large growth that appears to be directly related to the FacesServlet initialization (navigation handlers, etc). I looked into calling the FacesContext.release() method which seems to have purpose similar to that of the LogFactory.release() method. However, at the time of the contextDestroyed() invocation, FacesContext.getCurrentInstance() always returns null, so I do not ever have an opportunity to invoke the release method that I am aware of. If my suspicions are correct, than I would likely be able to avoid this problem entirely by simply placing the JSF implementation jars in the conatiner's shared lib dir - instead of bundling it inside WEB-INF/lib. However, this is not an option for this container as multiple web apps (which require the flexibility to use differing JSF implementations and versions - i.e. RI vs MyFaces, etc) will run on this container.
I don't believe it is at all related to the problem at hand, but my container is JBoss 4.0.2.
Any and all assistance and suggestion will be greatly appreciated! Has anyone else seen this sort of behavior? Are there any work arounds or corrective actions?
TIA

Has anyone else run into this? I'd greatly appreciate any assistance as I cannot seem to resolve this hot-deploy related leak.

App Memory Leak When Open iPhoto

Hi everyone,
Does anyone have experienced app memory leak when open iPhoto? My free memory immediate dropped from 5000 mb to 15mb when I open iPhoto and the app never open. If I force to quit iPhoto, all return to normal and everything work fine. I only have iPhoto app running, not sure what caused the memory leak???
Looking for help.
Thanks
JHML

Actually the new library was a test to see if the problem occurred only with your current library or with all libraries. The fact that switching libraries cleared up the problem is just serendipitous.

Yosemite - Mail.app memory leak

I'm seeing a recurring issue with Mail.app taking up huge amounts of RAM memory. There's evidently a serious memory leak in Yosemite Mail. On three occasions today, I noticed my free memory below 20 MB (I have 16GB). Activity Monitor shows the culprit to be Mail.app taking any where from 20-65GB of memory! I've had to quit Mail and restart it, only to have the same issue surface later. Does anyone have a way to mitigate/resolve this issue?

I apologize this is not the Discussion that has all the solutions. It's this one:
Yosemite OS 10.10 Mail Memory Leak
There are 19 pages so far, I'll see if I can find my post with the suggestions. Found it, it was on page 7. Here ya go. Hope it works!
Doren_Sean_Michael
Oct 23, 2014 8:47 PM
Re: Yosemite OS 10.10 Mail Memory Leak
Re: Yosemite OS 10.10 Mail Memory Leak
in response to Doug Lerner2
Thanks mlwebber & etresoft. I think we were able to narrow down the 4 most effective methods of temporarily resolving this issue it seems. I only had to disable the drafts to get back to normal, but others are reporting that using that in conjunction with a combination of 3 of the other methods from mlwebber are resolving their issues. Albeit this is only a temp fix until Apple updates their software & truly fixes this bug/issue, but, at least, I hope, we all can get back to business as normal for the time being.
Doren (from etresoft’s observations):
- Preferences/Accounts/Mailbox Behaviors: UNCHECK “Store draft messages on the server”
mlwebber:
- Preferences/Accounts/Advanced: UNCHECK “Use IDLE command if the server supports it”
- Preferences/General/Check for new messages: “Every 5 minutes”
- Preferences/Junk Mail: UNCHECK “Enable junk mail filtering”
Please post in this discussion if none of these methods help you and we'll see what we can do. We'd also love to know if these methods also resolve your issue. Thank you.

Memory Leak in PDA Example App.

Similar Messages

Maybe you are looking for