Hi support
We are using your Wpf DesktopEdition map control as main component in our map solution.
During test we discovered that in some scenarios, WpfMap control is not released from memory if it was dynamically added to the WPF.ContentHolder control.
Particularly, UserControl that wraps WpfMap resides in memory even after all references to it was released.
I could not find any mention of that kind of bug in forums so far.
Is there is special procedure on releasing WpfMap control? Where to read about it?
In attachment you can find “sandbox” test app, where leak is narrowed to the WpfControl.
Looking for forward to hear from you.
With kind regards
Alexey
ThinkGeoMemTest.zip (11.8 KB)
Memory leak: ContentPresenter cannot release ThinkGeo.MapSuite.WpfDesktopEdition.WpfMap control
Hi Alexey,
It looks if you set the dispose function in ThinkGeoMapTestControl like this:
public void Dispose()
{
_BLOB = null;
map.Dispose();
map = null;
}
It can release the memory back.
If I misunderstand you please let me know.
Regards,
Don
Hi Don,
Thank you for reply.
I added large _BLOB to make memory leak more vivid.
Problem in fact that UserControl that hosts _BLOB refuses to dispose.
And cause for it, as i see it, WpfMap control.
As you can see in the sample, other controls (TestControl and TestControl2) can successfully release memory without null-ing _BLOB.
So, problem is same: if i set ContentHolder.Content to user control, that contains WpfMap control, that control refuses to unload from memory afterwards whatever i try to do.
Hope that clarify situation.
Can you suggest any way to force WpfMap to unload?
Thank you
Regards
Alexey
Hi Alexey,
In fact our map control will open some thread, and after map control initialization, not all the threads can be closed immediately. But it will be released some time later. You can see, if you use my code, the memory of map looks is released.
So I have some thinking about this:
1. Could you please try to modify your GC like this:
GC.Collect(4, GCCollectionMode.Forced);
GC.WaitForPendingFinalizers();
2. When you dispose the custom control contains map, could you call write code to manual release other resource in same control?
Regards,
Don
Hi Don
thank you for reply. I tried fix suggested by you (and other workarounds too) with no success (you can easily ensure that yourself with test application supplied).
Also, i removed _BLOB at all from the UserControl since it does not affect overall Dispose scenario (and was introduced exclusively to make memory leak more visible).
Anyway, GC.Collect does not solve the problem. Neither combined with WaitPendingFinalizers or external memory pressure:
after removing _BLOB from the ThinkGeoMapTestControl, application still leak ~50-100 kb every time ThinkGeoMapTestControl is disposed.
NB: this is critical error since our application reloads views often and beside ThinkGeo.WpfMap, containing user control holds references to big data structures, which thus must be disposed explicitly (which is not always possible).
Do you have another solution proposal for this?
Should i open support ticket for this issue?
Thank you in advance.
Regards,
Alexey
Hi Alexey,
Thanks for your information, yes when we remove _BLOB we still can keep get a increase when we switch between ThinkGeoMapTestControl and the first empty item, and this memory hadn’t been watched to release, does this your issue?
I will let our developers knows it and please wait for our update.
Regards,
Don
Hi Don
yes that is an issue for several reasons:
* firstly, that is memory leak (for software that meant to run without restarts for several days, if possible weeks - it is an issue!)
* second, as i mentioned before, in our software, UserControl that hosts WpfMap also attached to significant data model (dozens to hundreds megabyte) , and THAT is real issue!
(As workaround we try to dispose manually whatever possible, to minimize loss of the memory, but that makes software slower and is unnecessary effort - if there were no memory leak first place)
So far, thank you for status update.
When can we expect update on this case?
Regards
Alexey
Hi Alexey,
I think our developer have found the reason and it should have been fixed. We tested that with your sample, the memory usage won’t keep increase now.
Please get the version 9.0.119.0 (9.0.0.119) or higher version to get this fix, and let us know whether that solve your problem.
Regards,
Don
Hi Don
Build 9.0.119.0 that fixes this problem, will that be available tommorrow?
/Morten
When will the fix be part of a full production build?
Hi Morten,
I think both of production and development version should have fixed this.
Regards,
Don
Hi Don
So far I only see
Full Production 9.0.0.97
Full Development 9.0.117.0
available in Product Center.
I assume this problem is not fixed in 0.97 since it is released on the same day as 0.117.0, so when will the new versions be available?
/Morten
Hi Morten,
I have asked our release manager, it looks today’s production version should be update.
Regards,
Don
Full Production is still at 9.0.0.97.
Please update this thread when you have news about when the version will arrive.
Hi Morten,
It looks our daily build met some problem, I will update here if I found the new version update succeed.
Regards,
Don
If anybody else is waiting for the build I can inform you that Full Production is now at 9.0.0.125, so I assume the bug is fixed.
Hi Morten,
Thanks for let us know that solved your issue.
Regards,
Don
Hi Don
returning to this case: i can confirm that memory leak is solved: WpfMap successfully unloaded from memory!
Thanx!
PS: Though, semantics of the WpfMap.IDisposable changed - now it is necessary to invoke map.Dispose(); explicitly (setting references to null is not enough). But that is OK.
br Alex
Hi Alex,
Thanks for your feedback, any question please let us know.
Regards,
Don