Memory leak in thread showing images.

I get the different images(call getImage()) from a thread, and show it in repaint(),But the more and more memory the applet used, after a long time. I have called the image.flush(),then set image=null , why does it do so? I am puzzling it. Thinking that it is possible the thread's reason, I set the function renew image with "synchronized", but it is not well. how about it???

I have the same problem here.
The bug you found seems pretty unsolved. I tried to add a MediaLibrary to my application (to ensure that an image is loaded only once, that it is flushed and cleared as soon as it is not needed enymore), I added much clean up code, but this wasn't helping.
Did you find any useful hints?
I'm running out of ideas. Maybe a self-written import filter for images would help. Of course pretty much work :-(

Similar Messages

  • Memory leak when creating new thread.

    Hi,
    Each time i create a thread, it causes 8 bytes memory leak. The testing code is as below and you can see mem usage increasing in Windows Task Manager. But if i don't call ::OCIEnvCreate(), no memory leak.
    Memory validator shows the following call stack information:
    ........largest allocation 8 bytes at .......
    =>OraOCIEI10.dll ss_mem_thread_attach
    =>OraOCIEI10.dll sscoresetserverflag
    =>OraOCIEI10.dll slzgetevar
    =>ntdll.dll LdrInitializeThunk
    Anyone knows what is goiing on?
    /Yue
    #include <stdio.h>
    #include <windows.h>
    #include <process.h>
    #include <oci.h>
    static OCIEnv *env;
    static unsigned int counter = 0;
    unsigned __stdcall ThreadFunc(void* pArg)
    counter++;
    printf( "In %uth thread...\n", counter );
    Sleep(100);
    _endthreadex( 0 );
    return 0;
    int main( int argc, const char* argv[] )
         sword rc = ::OCIEnvCreate(&env, OCI_DEFAULT, NULL, NULL, NULL, NULL, 0, NULL );
         for(;;)
              HANDLE hThread;
              unsigned threadID;
              // Create the second thread.
              hThread = (HANDLE)_beginthreadex( NULL, 0, &ThreadFunc, NULL, 0, &threadID );
              WaitForSingleObject( hThread, INFINITE );
              // Destroy the thread object.
              CloseHandle( hThread );
         return 0;
    }

    Hi,
    I'm not suprised.
    OCI offers the feature OCIThreadKey that allow you to store a pointer within a thread context (without using OCIThread, just using natives threads).
    So OCI needs to catch thread creation to be able to register storage for its OCIThread key value and be able, once the thread is finished to call a callback with the pointer value associated with the thread....

  • Memory Leak in edited images?

    I am using Captivate 4.0.1 Build 1658 (this means that the patch from May 2009 is applied) on Windows Vista.
    The following has happened to myself and at least 2 other developers.
    We edit a slide background image in Photoshop...when the  movie plays, a flash of the previously unedited background shows.  I have tried re-editing the background and it does not fix the problem. I have tried eliminating transistions and it does not fix the problem.  I have noticed that this happens when background images are edited in Photoshop as well as within Captivate when bitmaps are pasted onto a slide background and then merged into the background.
    I don't know if the correct term for this is a memory leak, but the closest mention of this problem I could find was here: http://blogs.adobe.com/captivate/2009/05/captvate_4_patch_update.html
    I appreciate any help resolving this.
    Thank you,
    Beth

    The Reset Firefox feature can fix many issues by restoring Firefox to its factory default state while saving your essential information.
    Note: ''This will cause you to lose any Extensions, Open websites, and some Preferences.''
    To Reset Firefox do the following:
    #Go to Firefox > Help > Troubleshooting Information.
    #Click the "Reset Firefox" button.
    #Firefox will close and reset. After Firefox is done, it will show a window with the information that is imported. Click Finish.
    #Firefox will open with all factory defaults applied.
    Further information can be found in the [[Reset Firefox – easily fix most problems]] article.
    Did this fix your problems? Please report back to us!

  • Easy to produce - Memory Leak in JVM Using thread

    I was just debugging the problem with our server and got this error (not from the original code, I reproduced it with small code)
    at java.lang.Thread.run(Unknown Source)
    java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Unknown Source)
    at SomeObject.resursiveThreadGeneratorMethod(ThreadRecursionLeak.java:12
    at ClientThread.run(ThreadRecursionLeak.java:27)
    it is just a simple program generating thread recursively with a lock on an object
    import java.lang.Runnable;
    import java.lang.Thread;
    //     <<Objec/Monitor Class>>
         class SomeObject{
              public synchronized void resursiveThreadGeneratorMethod(int threadNumber, int k){
                   if(k<=0)
                        return;
                   else{
                        System.out.println("Thread: "+threadNumber + "call number: "+k);
                        Thread thread=new Thread(new ClientThread(this));
                        thread.start();
                        resursiveThreadGeneratorMethod(threadNumber,k-1);
    //     <<Thread Class>>
         class ClientThread implements Runnable{
              SomeObject someObject=null;
              public static int threadNumber;
              public ClientThread(SomeObject someObject){
                   this.someObject=someObject;
                   threadNumber++;
              public void run(){
                   someObject.resursiveThreadGeneratorMethod(this.threadNumber,10);
    //     <<Driver Class>>
         public class ThreadRecursionLeak{
              public static void main(String [] args){
                   SomeObject someObject=new SomeObject();
                   Thread thread=new Thread(new ClientThread(someObject));
                   thread.start();
    is there any way I can monitor JVM memory status (programatically), kill those threads leading to memory leak and send notification to the system admin.
    We run JVM 1.4 on the server and need to address this issue as we do not have control over the code that can be submitted to the server, we just do some checks and then let it run on the servers.
    Our main requirement is to keep JVM alive and kill all those code and report them.
    Message was edited by:
    rajanikant_malviya

    You can monitor the JVM with the
    [url=http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/i
    ndex.html]JVMPI if you're using the Sun JVM.This is native code that basically gets
    notified anytime the JVM does something
    interesting.
    However, you're going to have a very difficult time
    catching code that does what the code you show does.
    I'm not sure I understand your environment - you
    allow people to submit code and you run it? Are you
    running it in the same JVM as your server? That
    seems like a huge issue. A simple System.exit()
    code will take down your server.
    Let us know some more details.
    We are actually having a portal through witch users can submit their code, witch are basically utility codes for different operations teams.
    we then provide a way to schedule them.
    At the background, we are having 6 (Win) servers where at each server we are having 20 to 25 users on different ports (managed by our application) running there own JVMs. When a schedule is met we just invoke a servlet (on any free port) and pass code id (stored in DB). And this servlet is responsible for compilation and exicution of the code (We just use Runtime to fork this new process).
    I don't know, but is there any way through witch I can monitor this process and restrict to generate threads recursively???

  • Callbacks without excessive thread creation and memory leaks?

    Hi JNI experts,
    I haven't done any serious JNI programming in a couple years and I'm currently stuck with a tricky JNI problem:
    My JNI code is connected to a system driver and needs to do frequent callbacks into Java code. The standard way of doing this involves calling AttachCurrentThread and DetachCurrentThread before/after the callback to Java code. However, I noticed that AttachCurrentThread creates a new java.lang.Thread each time it is invoked. Let's just say that the callback is invoked from JNI very freqently, and creating a new Thread each time that happens is not acceptable behavior for my application. Among other things, it prevents me from using the Eclipse debugger because the large number of threads being created and destroyed effectively locks up Eclipse's debugger UI. Also, it creates a CPU load that is way higher than it should be for a light-weight operation.
    So, I deviated from the standard Attach/DetachCurrentThread pattern and moved the DetachCurrentThread to code that is only called when the native JNI service is terminated. As that effectively renders repeated AttachCurrentThread calls a no-op, the problem of excessive creation and destruction of threads went away, but instead I had a memory leak on my hands now. The JNI code needs to create some Java objects because it's easier to create those objects right away rather than passing a bunch of primitives to Java and assembling them into objects there. When I moved the DetachCurrentThread, those newly created objects were no longer garbage-collected even after the Java code had released all references.
    When you print the stack trace of the Java callback method there is always only one frame on the stack (since it is being invoked directly from JNI). However, I suspect that older stack frames from previous invocations keep hanging around somewhere else in memory if DetachCurrentThread is not called. In other words, moving DetachCurrentThread out of the callback is an even worse option. I tried using PopLocalFrame to get rid of left over stack frames, but that didn't seem to work.
    So, my question is: is there a way to make (natively initiated) callbacks from JNI to Java without memory leaks and without creating a new thread each time? Would it work if I created my own native thread that runs some sort of dispatch loop? What other options are there?
    Thanks for any ideas!

    Thanks for the quick reply, ejp! :-)
    Your comments were very helpful; let me clarify a few things:
    I don't know where you get this 'standard Attach/DetachCurrentThread pattern', but if the native callbacks always happen on the same native thread, you only need to attach it once when you get the first callback, and detach it when you get the last, if you can tell. ;-)Yes, the callback is always coming from the same native thread, but, unfortunately, I cannot tell when I get the last callback, and essentially the native service keeps running as long as the VM is running. When I say "standard pattern" I'm referring to the fact that pretty much every book, tutorial, or web site that talks about JNI callbacks shows code snippets where AttachCurrentThread is called, then the callback, and then DetachCurrentThread.
    The JNI code needs to create some Java objects because it's easier to create those objects right away rather than passing a bunch of primitives to Java and assembling them into objects there.Is it really? Are you sure?I'm pretty sure in this case, though your point is well taken. The native API that calls my JNI code produces packets of that contain about 15 pieces of information of different types (ints, longs, doubles). Several packets may arrive together in a single group. Handling the data on the Java side requires a Java callback method with 15 parameters for a single packet, and it's hard to reconstruct which packets belong to one group at that point. Creating corresponding Java objects in JNI and passing them inside an array to the callback function indeed turned out to be easier.
    I don't think just 'moving' the DetachCurrentThread is correct. You need to attach the thread that is doing the callbacks, as often as necessary but no oftener, and detach it when you can.I think I found the solution: my native code is starting a separate dispatcher thread that, as you suggested, attaches itself only once and then enters a dispatcher loop. The low-level call back function notifies that thread of new data via the standard Pthread API. The detach happens in JNI_OnUnload. This works without creating a new thread each time and garbage-collects the created objects properly. As the dispatcher method essentially never returns I also had to insert some DeleteLocalRef calls, because otherwise the local references prevented garbage collection.
    So, for now, it looks like I'm good to go. Thanks again for the reply!

  • Memory leak with multi-threaded environment

    When starting an environment with the THREADED_MUTEXED
    or THREADED_UNMUTEXED mode parameter, the oracle OCCI API
    has a memory leak. This can be demonstrated by modifying
    the "occidml.cpp" demo program as follows:
    Replace line 26:
    env = Environment::createEnvironment (Environment::DEFAULT);
    with
    env = Environment::createEnvironment (Environment::THREADED_MUTEXED);
    And replace line 164:
    demo->displayAllRows();
    with
    for (int ii=0; ii<10000; ii++) demo->displayAllRows();
    Recompile and run the program, and use "top" to see the
    size of the process's used memory continually increase
    unbounded.
    I am using the Oracle 9.2.0.1.0 database on Linux,
    gcc version 2.96.
    Is anyone aware of a fix for this problem?

    Yeah, I did suffer from this.
    If possible , you can switch to using OCCI on Oracle 10G client , you will find no memory leak issue anymore.
    Another issue is that OCCI is using default connection-blocking implementation , if a DB connection is blocked by accident just like plugging out the network link, you can not get any timeout or connection closed indications. You must implement your own OCCI connection timeout strategy, and you must kill the thread/process you are using.

  • 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

  • Memory leak in image rings on Linux

    Hello all,
    I have a very serious problem I didn't have in previous version of my soft and one of the only addition I've made recently is to use image rings. The soft uses 6Mb more every minute. If I remove the rings, it stops. It could be a wrong lead, so I'm trying to write a test case, but is there a list of identified memory leaks somewhere ?
    THanks.
    Solved!
    Go to Solution.

    OK guys, there's a very serious leak on Linux, confirmed by the code below. Every time you change the value of a picture ring, either by clicking on the arrow of the picture ring or right-click on it (callback to SetCtrlVal), it uses 1 extra Mb of mem for a 512x512 pixel image !!!
    Here's a sample code:
    // Right-click the ring to cause memory leak
    #include <stdio.h>
    #include <stdlib.h>
    #include <cvirte.h>
    #include <userint.h>
    #define RND_COLOR (((rand()<<16) ^ (rand()<<8) ^ rand()) & 0xFFFFFF)
    // (int)((double)(0xFFFFFF)*rand()/RAND_MAX)
    static int Pnl=0,
    Text, Ring, // Controls
    NbVals=16, // Number of images in the ring
    Width=512, Height=512; // Of the Canvas and image ring
    // Returns memory used by process in 4Kb page:
    // TotalSize Resident Share Text Lib Data Dirty
    // See "man proc" section statm
    static char* ReadOffMemoryStatus(void) {
    static char statm[80];
    statm[0]='\0';
    #ifdef _NI_linux_
    FILE *f = fopen("/proc/self/statm","r");
    if (f)
    fgets (statm, 79, f),
    fclose(f);
    #endif
    return statm;
    static void Prepare(const int Nb) {
    Point polyPoints[10]={{0,0}};
    char Str[10];
    int i, Bitmap;
    int Canvas=NewCtrl(Pnl, CTRL_CANVAS, "", 0, 0);
    SetCtrlAttribute(Pnl, Canvas, ATTR_DRAW_POLICY, VAL_UPDATE_IMMEDIATELY);
    SetCtrlAttribute(Pnl, Canvas, ATTR_WIDTH, Width);
    SetCtrlAttribute(Pnl, Canvas, ATTR_HEIGHT, Height);
    // SetCtrlAttribute(Pnl, Canvas, ATTR_ENABLE_ANTI_ALIASING, 1); // No compile on Linux
    SetCtrlAttribute(Pnl, Canvas, ATTR_PICT_BGCOLOR, RND_COLOR /*VAL_TRANSPARENT*/);
    SetCtrlAttribute(Pnl, Canvas, ATTR_PEN_FILL_COLOR, RND_COLOR);
    SetCtrlAttribute(Pnl, Canvas, ATTR_PEN_COLOR, RND_COLOR);
    SetCtrlAttribute(Pnl, Canvas, ATTR_PEN_WIDTH, 7);
    for (i=0; i<10; i++)
    polyPoints[i].x=(Width*rand()/RAND_MAX),
    polyPoints[i].y=(Height*rand()/RAND_MAX);
    sprintf(Str, "%d", Nb);
    // CanvasStartBatchDraw(Pnl, Canvas);
    // This sometimes doesn't work on Linux
    CanvasDrawPoly (Pnl, Canvas, 10, polyPoints, 1, VAL_DRAW_FRAME_AND_INTERIOR);
    CanvasDrawLine (Pnl, Canvas, MakePoint(Width-1,0), MakePoint(0, Height-1));
    SetCtrlAttribute(Pnl, Canvas, ATTR_PEN_COLOR, VAL_BLACK);
    SetCtrlAttribute(Pnl, Canvas, ATTR_PEN_FILL_COLOR, VAL_WHITE);
    CanvasDrawText(Pnl, Canvas, Str, VAL_APP_META_FONT,
    MakeRect (2, 2, VAL_KEEP_SAME_SIZE, VAL_KEEP_SAME_SIZE), VAL_UPPER_LEFT);
    // CanvasEndBatchDraw(Pnl, Canvas);
    GetCtrlBitmap(Pnl, Canvas, 0, &Bitmap);
    DiscardCtrl (Pnl, Canvas);
    InsertListItem(Pnl, Ring, Nb, NULL, Nb); // The value is the color, so remember which one you use
    SetCtrlBitmap (Pnl, Ring, Nb, Bitmap);
    DiscardBitmap (Bitmap);
    int CVICALLBACK cb_Change(int panel, int control, int event,
    void *callbackData, int eventData1, int eventData2) {
    static int i=0;
    switch (event) {
    case EVENT_RIGHT_CLICK:
    case EVENT_RIGHT_DOUBLE_CLICK:
    SetCtrlVal(Pnl, Ring, i=(i+1)%NbVals);
    // No break;
    case EVENT_COMMIT:
    SetCtrlVal(Pnl, Text, ReadOffMemoryStatus());
    break;
    return 0;
    int CVICALLBACK cb_Quit(int panel, int control, int event,
    void *callbackData, int eventData1, int eventData2) {
    switch (event) {
    case EVENT_COMMIT: QuitUserInterface (0); break;
    return 0;
    int main (int argc, char *argv[]) {
    int i, Quit;
    if (InitCVIRTE (0, argv, 0) == 0) return -1;
    Pnl = NewPanel (0, "Test image ring", 20, 20, Height+20, Width);
    Text = NewCtrl (Pnl, CTRL_STRING_LS, "Memory use (in 4Kb pages)", 0, 0);
    Ring = NewCtrl (Pnl, CTRL_PICTURE_RING, "", 20, 0);
    Quit = NewCtrl (Pnl, CTRL_SQUARE_BUTTON_LS, "", 50, 50);
    SetCtrlAttribute(Pnl, Ring, ATTR_HEIGHT, Height);
    SetCtrlAttribute(Pnl, Ring, ATTR_WIDTH, Width);
    SetCtrlAttribute (Pnl, Ring, ATTR_CTRL_MODE, VAL_HOT);
    SetCtrlAttribute(Pnl, Ring, ATTR_CALLBACK_FUNCTION_POINTER, cb_Change);
    for (i=0; i<NbVals; i++) Prepare(i);
    SetCtrlAttribute(Pnl, Text, ATTR_WIDTH, 250);
    SetCtrlAttribute(Pnl, Text, ATTR_LABEL_LEFT, 250);
    SetCtrlAttribute(Pnl, Text, ATTR_LABEL_TOP, 0);
    SetCtrlAttribute(Pnl, Quit, ATTR_CALLBACK_FUNCTION_POINTER, cb_Quit);
    SetCtrlAttribute(Pnl, Quit, ATTR_VISIBLE, 0);
    SetCtrlAttribute(Pnl, Quit, ATTR_SHORTCUT_KEY, VAL_ESC_VKEY);
    SetPanelAttribute(Pnl, ATTR_CLOSE_CTRL, Quit);
    DisplayPanel (Pnl);
    RunUserInterface ();
    return 0;
    There are other issues as well:
     - CanvasDrawPoly sometimes doesn't work.
     - The anti-aliasing on a canvas doesn't compile.
    Is there anything more recent than CVI 2010 for Linux ?!?

  • 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

  • TestStand 2010 Memory Leak when calling sequence in New Thread or New Execution

    Version:  TestStand 4.5.0.310
    OS:  Windows XP
    Steps to reproduce:
    1) Unzip 2 attached sequences into this folder:  C:\New Thread Memory Leak
    2) Open "New Thread Memory Leak - Client" SEQ file in TestStand 2010
    3) Open Task Manager, click Processes tab, sort A-Z (important), and highlight the "SeqEdit.exe" process.  Note the memory useage.
    4) Be ready to click Terminate All in TestStand after you see the memory start jumping.
    5) Run the "New Thread Memory Leak - Client" sequence.
    6) After seeing the memory consumption increase rapidly in Task Manager, press Terminate All in TestStand.
    7) Right click the "While Loop - No Wait (New Thread)" step and set Run Mode » Skip
    8) Right click the "While Loop - No Wait (New Execution)" step and set Run Mode » Normal
    9) Repeat steps 3 through 6
    I've removed all steps from the While Loop to isolate the problem.  I've also tried the other methods you'll see in the ZIP file but all cause the memory leak (with the exception of the Message Popup).
    I have not installed the f1 patch, but none of the bug fixes listed appear to address this issue.  NI Applications Engineering has been able to reproduce the issue (with Windows 7) and is working on it in parallel.  That said, are we missing something??
    Any ideas?
    Certified LabVIEW Architect
    Wait for Flag / Set Flag
    Separate Views from Implementation for Strict Type Defs
    Solved!
    Go to Solution.
    Attachments:
    New Thread Memory Leak.zip ‏14 KB

    Good point Doug.  In this case parallel sequences are being launched at the beginning of the sequential process model, but I'll keep that in mind for later.  Take away:  be intentional about when to wait at the end of the sequence for threads to complete.
    Certified LabVIEW Architect
    Wait for Flag / Set Flag
    Separate Views from Implementation for Strict Type Defs

  • Memory leak when using Threads?

    I did an experiment and noticed a memory leak when I was using threads.. Here's what I did.
    ======================================
    while( true )
         Scanner sc = new Scanner(System.in);
         String answer;
         System.out.print("Press Enter to continue...");
         answer = sc.next();
         new TestThread();
    ========================================
    And TestThead is the following
    ========================================
    import java.io.*;
    import java.net.*;
    public class TestThread extends Thread
    public TestThread() { start(); }
    public void run() {  }
    =====================================
    When I open windows Task Manager, every time a new thread starts and stops, the java.exe increases the Mem Usage.. Its a memory leak!? What is going on in this situation.. If I start a thread and the it stops, and then I start a new thread, why does it use more memory?
    -Brian

    MoveScanner sc = new
    Scanner(System.in);out of the
    loop.Scanner sc = new Scanner(System.in);
    while (true) {
    That won't matter in any meaningful way.
    Every loop iteration creates a new Scanner, but it also makes a Scanner eligible for GC, so the net memory requirement of the program is constant.
    Now, of course, it's possible that the VM won't bother GCing until 64 MB worth of Scanners have been created, but we don't care about that. If we're allowing the GC 64 MB, then we don't care how it uses it or when it cleans it up.

  • Applescript Image Events appears to have memory leak (or I don't know what I am doing)

    Using Image Events to create images and thumbnails for a website. The following code results in very large memory leaks in Image Event process. I have documented results of test runs in the comments.
    The leak (or poor coding on my part) results in a total system halt if I attempt to process more than about 400 images at a time. Basically, I run out ot physical memory. I am running a new model 13" MBP with 8GM RAM.  I have to manually stop Image Events to reclaim the memory (or reboot of course).
    Any help/suggestions would be appreciated.
    (* test memory leak in Image Events *)
              tests with 58 photos selected in iPhoto
              5.7 MB left in Image Events after run with only open and close
              22.0 MB left in Image Events after run with open, save and close
              45.9 MB left in Image Events after run with open, scale, save and close
              A run with 382 photos selected used OVER 3.8 GB (gigabytes) and the
              mac ran out of physical memory so I had to stop the test.
    tell application "Finder"
              set imageFolder to folder "test" of home as alias
    end tell
    tell application "iPhoto"
              set currPhotoList to the selection
              repeat with currPhoto in currPhotoList
                        log name of currPhoto as string
                        set theImagePath to image path of currPhoto
                        tell application "Image Events"
      launch
                                  set theImage to open theImagePath
      scale theImage to size 128
      save theImage in imageFolder as JPEG with icon
      close theImage
                        end tell
              end repeat
    end tell
    --- end of code example

    Does the following code do any difference? Most likely no I guess… but better try than nothing.
    tell application "Finder"
        set imageFolder to folder "test" of home as text -- instead of “as alias” (see theTargetPath below)
    end tell
    set theImagePaths to {}
    set theImagePathsRef to a reference to theImagePaths -- faster with big lists
    tell application "iPhoto"
        set currPhotoList to the selection
        repeat with currPhoto in currPhotoList
            log name of currPhoto as string
            get POSIX file (image path of currPhoto) as alias -- faster ?
            copy result to the end of theImagePathsRef
        end repeat
    end tell
    tell application "Image Events"
        launch
        repeat with theImagePath in theImagePaths
            set theImage to open theImagePath
            scale theImage to size 128
            set theTargetPath to (imageFolder & name of theImagePath)
            save theImage in theTargetPath as JPEG with icon
            close theImage
        end repeat
    end tell

  • Nasty memory leak using sockets inside threads

    In short, any time I create or use a socket inside a worker thread, that Thread object instance will never be garbage collected. The socket does not need to be connected or bound, it doesn't matter whether I close the socket or not, and it doesn't matter whether I create the Socket object inside the thread or not. As I said, it's nasty.
    I initially encountered this memory leak using httpclient (which creates a worker thread for every connect() call), but it is very easy to reproduce with a small amount of stand-alone code. I'm running this test on Windows, and I encounter this memory leak using the latest 1.5 and 1.6 JDK's. I'm using the NetBeans 5.5 profiler to verify which objects are not being freed.
    Here's how to reproduce it with an unbound socket created inside a worker thread:
    public class Test {
         public static class TestRun extends Thread {
              public void run() {
                   new Socket();
         public static void main(String[] strArgs) throws Exception {
              for(;;) {
                   (new TestRun()).start();
                   Thread.sleep(10);
    }Here's how to reproduce it with a socket created outside the thread and used inside the worker thread:
    public class Test {
         public static class TestRun extends Thread {
              Socket s;
              public TestRun(Socket s) { this.s = s; }
              public void run() {
                   try {
                        s.bind(new InetSocketAddress(0));
                        s.close();
                   } catch(Exception e) {}
         public static void main(String[] strArgs) throws Exception {
              for(;;) {
                   (new TestRun(new Socket())).start();
                   Thread.sleep(10);
    }Here's how to reproduce it implementing Runnable instead of extending Thread:
    public class Test {
         public static class TestRun implements Runnable {
              public void run() {
                   Socket s = new Socket();
                   try { s.close(); } catch(Exception e) {}
         public static void main(String[] strArgs) throws Exception {
              for(;;) {
                   (new Thread(new TestRun())).start();
                   Thread.sleep(10);
    }I've played with this a lot, and no matter what I do the Thread instance leaks if I create/use a socket inside it. The Socket instance gets cleaned up properly, as well as the TestRun instance when it's implementing Runnable, but the Thread instance never gets cleaned up. I can't see anything that would be holding a reference to it, so I can only imagine it's a problem with the JVM.
    Please let me know if you can help me out with this,
    Sean

    Find out what is being leaked. In the sample programs, add something like this:
        static int loop_count;
            while (true) {
                if (++count >= 1000) {
              System.gc();
              Thread.sleep(500); // In case gc is async
              System.gc();
              Thread.sleep(500);
              System.exit(0);
            }Then run with java -Xrunhprof:heap=sites YourProgram
    At program exit you get the file java.hprof.txt which contains something like this towards the end of the file:
              percent          live          alloc'ed  stack class
    rank   self  accum     bytes objs     bytes  objs trace name
        1  0.47%  0.47%       736    5       736     5 300036 char[]
        2  0.39%  0.87%       616    3       616     3 300000 java.lang.Thread
        3  0.30%  1.17%       472    2       472     2 300011 java.lang.ThreadLocal$ThreadLocalMap$Entry[]
        4  0.27%  1.43%       416    2       416     2 300225 java.net.InetAddress$Cache$Type[]See, only three live Thread objects (the JVM allocates a few threads internally, plus there is the thread running main()). No leak there. Your application probably has some type of object that it's retaining. Look at "live bytes" and "live objs" to see where your memory is going. The "stack trace" column refers to the "TRACE nnnnn"'s earlier in the file, look at those to see where the leaked objects are allocated.
    Other quickies to track allocation:
    Print stats at program exit:
    java -Xaprof YourProgram
    If your JDK comes with the demo "heapViewer.dll" (or
    heapViewer.so or whatever dynamic libraries are called on your system):
    java -agentpath:"c:\Program Files\Java\jdk1.6.0\demo\jvmti\heapViewer\lib\heapViewer.dll" YourProgram
    Will print out statistics at program exit or when you hit Control-\ (Unix) or Control-Break (Windows).

  • Scale Image Memory Leak

    There seems to be a memory leak in the Image.getScaledInstance(...) method when used in the following code:
    if(scanImage.getWidth(this) > scanImage.getHeight(this))
        scanImage =  scanImage.getScaledInstance(300, -1, Image.SCALE_DEFAULT);
    else
        scanImage =  scanImage.getScaledInstance(-1, 300, Image.SCALE_DEFAULT);
    }Any ideas why its leaking, or another way of doing scaling?

    hi
    memory problems with this method seem to be common. here is another way of scaling images:
    Iterator readers = ImageIO.getImageReadersByFormatName("gif");
    ImageReader reader = (ImageReader)readers.next();
    ImageInputStream iis = ImageIO.createImageInputStream(new File(path));               
    reader.setInput(iis, true);
    ImageReadParam param = reader.getDefaultReadParam();
    param.setSourceRenderSize(new Dimension(width, height));
    BufferedImage thumbnail = reader.read(0, param);
    this does not work for jpeg images and you need the sdk 1.4.2 in order to use ImageIO. previous versions do not have this framework.

  • When firefox crashes from a memory leak why can't you display the offending tab? Enhancement: a task manager like tab manager showing usage per tab / extension.

    I typically keep many windows with several tabs open. It is possible that this causes more crashes since the number of pages multiplies any effect most users with less pages/tabs would experience. I have been having problems with Firefox crashing Using the windows task manager I have looked into this issue monitoring lots of variables. Bottom line the crash is caused by increasing memory usage possibly caused by the flash add on which is doing many IO reads on at least one offending page/tab. Could some sites be using flash to read from my disk without permission and there is a memory leak in either flash of the code the sites uses? I have searched the web for a task manager like add-on for Firefox tabs that would allow me to determine the offending page/tab/add-on/extension. It seems like a great idea which has not been implemented. Since I am a developer I would be happy to implement, but would like some guidance since my knowledge of your product is only at the user level.

    There is currently about:memory page which is being actively developed. A "task manager"of sorts is also in the works AFAIK. If you want to help out, your best bet is to find the applicable bug in Bugzilla. If you have the coding skills I can help get you in touch with a mentor - just let me know.

Maybe you are looking for