A lot of Preview image cause memory leak

[buddycat75]

This will result in memory leak --> Naviguator wont free any memory -->

var my_preloader = new moxie.image.Image();
myfunction {
       my_preloader.onload = function() {
            //resize and display thumbs
            my_preloader.destroy();
           my_preloader = null;
            setTimeout(lazyLoad, 1); //load, resize and display next image
        }
     
        my_preloader.load(file.getSource());
}

AND This is ok --> Naviguator reuse the same object -->

var reader  = new FileReader(); 
myfunction {
    reader.onloadend = function () {
          //resize and display thumbs
           setTimeout(lazyLoad, 1); //load, resize and display next image
          }
   
    reader.readAsDataURL(file.getNative());
}

PS If you only need preview (dont need to upload resized image)

Thanks in advance

[jayarjo]

Not sure in what part of this I should look into? Do you want to say that moxie.image.Image doesn't release memory even after it is destroyed?

[buddycat75]

Exactly
I do also test with original Plupload Exemple and if you generate 10 thumbs images (6mb each) you reach more then 500Mbyte memory in FireFox or Chrome

Destroy method do not free memory
(THANKS for your time ;-) )

[buddycat75]

Hi jayarjo,

Did you investigate about my issue ? I still have a lot of memory leaks problems

Thanks in advance

[jayarjo]

@buddycat75 no, still have no clue. While I did track down some zombie references in the heap, they didn't seem to contribute that much to the overall memory usage. It still continues to crawl up quickly (Firefox even managed to crash couple of times, when usage of memory exceeded 2gb). However if they survive initial load, memory usage eventually drops. And since there's no way to force garbage collection from javascript, I'd conclude here that that's simply the way those browsers are designed. They eat up memory as fast as possible while it's available and start to garbage collect only when there's a shortage of it.

Suggestions are welcome.

[jayarjo]

Some issues that might have caused memory leaks were fixed now. Also for those browsers that support blob uris, we will be using that, so won't have to preload as string and then convert.

[catester]

FYI, I found a bug which may be also causing @buddycat75's problem.

I noticed that after using image.getAsDataURL, I could not destroy the runtime when I called uploader.destroy() for Flash and Silverlight. The runtime.client was 1 and never 0 and as a result, Flash and Silverlight shims were still on the browse button.

In moxie/runtime/flash/image/Image (which is also inherited by Silverlight) I noticed there is a ghost blob object which is not destroyed anywhere so it causes the Flash and Silverlight runtimes to think there is still some connected object so they are not completely destroyed. I fixed by destroying the temp blob object before returning the dataUrl string:

getAsDataURL: function() {
    var self = this.getRuntime()
    , blob = self.Image.getAsBlob.apply(this, arguments)
    , frs
    ;
    if (!blob) {
        return null;
    }
    frs = new FileReaderSync();

    /**FIX**/
    //Fix memory leak for Flash and Silverlight, runtime is not destroyed because this blob is not destroyed
    var dataUrl = frs.readAsDataURL(blob);
    blob.destroy();
    return dataUrl;
    /** FIX **/
}

Note this problem was observed in moxie v1.5.7