Destroy of ListGrid gives memory leak in daterangeitem (filtereditor)

[martintaal]

Hi,
Thanks this works fine now.

gr. Martin

[martintaal]

Ha, okay, I see what the difference is, I did not do this part:
- click the "Nationhood" field filter editor icon to show the date range dialog

If I don't do this then I get an exception in isc_FormItem_saveValue (when clicking the destroy button):
TypeError: Cannot call method 'saveItemValue' of null

After I continue the global var: isc_MiniDateRangeItem_0_rangeDialog keeps it value.
Probably this javascript error is the cause of not having the reference being cleaned up.

If I show the rangedialog and then click destroy it indeed works fine.

Okay clear for now, I will check if I get this error myself locally and if so open a separate thread for it (and ofcourse if I can reproduce it with an example...).

Thanks!

gr. Martin

[Isomorphic]

In our testing we're not seeing this.
Here are our exact steps to test.

- download the build from http://www.smartclient.com/builds/Sm...val/2011-09-18
- unzip, and start via the start_embedded_server script
- in a browser (we're using Firefox), navigate to the "filter" example in the feature explorer at http://localhost:8080/isomorphic/sys...er.html#filter
- copy the code from the original post in this thread into the source tab and hit "Try It"
- click the "Nationhood" field filter editor icon to show the date range dialog
- open the developer console and evaluate "isc_MiniDateRangeItem_0_rangeDialog" - note that a live Dialog instance is reflected in the results text box
- in the app window, click the "Destroy" button
- in the developer console, re-evaluate "isc_MiniDateRangeItem_0_rangeDialog" - note that now the results text-box shows "null" as the result of this evaluation indicating the dialog has indeed been destroyed.

If you continue to see different results in your testing (and have verified that you aren't somehow looking at stale SmartClient code - easy to test by evaluating "isc.version"), please post full steps used in your testing (and any platform information etc that may be relevant)

[martintaal]

Hi,
Bumped up also...

gr. Martin

[martintaal]

Hi,
Tested with 8.1 build of 18th of september and still see some mem leak. See the attached screenshot. Tested with the above code snippet (see first post).

gr. Martin

[Isomorphic]

Please try again with the next nightly build (Sep 15th or greater). Let us know if you continue to hit problems

[martintaal]

Hi,
See the attached screenshot from the window object, with the above code, after destroying the isc_MiniDateRangeItem_0 is null, but its content is still present in the global vars.

Note: I updated the post, the previous screenshot was from the smartclient.com demo. The new screenshot (Screenshot-8) shows the result on the 8.1 nightly build from the 9th of september.

gr. Martin

[Isomorphic]

What exactly are you seeing get left around?
Can you show us test code, steps to reproduce? (Running the above test code it appears that after hitting the 'destroy' link the dateRangeForm is destroyed as expected).

[martintaal]

Hi,
I tested this today with a 8.x nightly of today and as far as I can see there are still minidaterange components which are not destroyed. I also tested with a 8.1 nightly and noticed the same issue.

gr. Martin

[martintaal]

Probably isomorphic can answer in more detail.

I have been checking memory leaks and the ones I find are caused by my own code (referencing objects which are not added as children), only saw this specific case which was different.

Btw, it is quite easy to find memory leaks:
- open your application (in my case this opens a main tabset with a starting tab which can't be closed)
- make a snapshot of all global variables starting with isc_, this is start snapshot
- work with your application
- close everything (in my cases all main tabs)
- check if there are any isc_* globals which are not-null and are not part of the initial snapshot

gr. Martin

[acarur01]

Is this issue specific to DateRangeItem?

[Isomorphic]

Thanks for the report - these things have been addressed today and will appear in upcoming nightlies

[martintaal]

Hi,
I am solving some memory leaks (caused by my own code) but also noticed something which seems to be an issue in Smartclient (not sure ofcourse).

If I have a daterange item in the filter editor then destroying the ListGrid keeps a global reference to the daterange item structure. See the code below. After calling destroy on the listgrid I still have a global reference: isc_DateRangeItem_1_dateRangeForm

isc.Button.create({
    ID: "destroy",
    title: "Destroy",
    top: 120,
    autoFit: true,
    click: function () {
       grid2.destroy();
    }
});

// ---------------------------------------------------------------------------------------
// Inline FilterEditor Example (MiniDateRangeItem)

isc.Label.create({
    contents: "FilterEditor (MiniDateRangeItem)",
    top: 280,
    width: "90%",
    height: 25,
    autoDraw: true,
    baseStyle: "exampleSeparator"
});

// Create a ListGrid displaying data from the worldDS and also displaying a FilterEditor
isc.ListGrid.create({
    ID: "grid2",
    top: 330, width: 595, height: 100,
    dataSource: "worldDS",
    autoFetchData: true,
    showFilterEditor: true
});

In my own code I have a DateRangeDialog added as autochild to a filter textitem, but the DateRangeDialog does not get destroyed automatically either. Maybe related, maybe not..

A related issue I found is that if I explicitly ca ll destroy on the DateRangeDialog that I get a NPE, this because the Canvas.destroy calls clear, in the DateRangeDialog the clear tries to clear the value in the form, but the form has already been set to null at that point (as the whole structure is being destroyed).

gr. Martin