none
Fall Creators 2017 Update: MapElementsLayer.Remove(obj) removes object but seems to leak memory until 2G and app crashes RRS feed

  • Question

  • Hi,

    We noticed in the documentation for this release it is advised to now use MapElementsLayer to show map objects, so we changed our code to use a MapElementsLayer.

    We are keeping very close of how items are in the layer via MapElementsLayer.MapElements.Count and we never have more than 30 as we add and delete various MapPolylines.  We add and remove alot of MapPolylines to show the footprint of satellites orbiting the earth.

    However, as we also keep track of total app memory for this UWP app, we notice that the overall memory goes up and up and up to 2G over a period of 2 days and then the system kills it.

    As a workaround, we also tried to Map.Layers.Remove(our MapElementLayer) and create a new one to use - this visually works well too, but the memory never stays the same, keeps going up and up.

    Question:  Is this memory leak a bug?  Or, is there a particular way to make the map flush out all the unused objects and associated memory?

    Best regards, Karhu.

    p.s. We like the changes/bug-fixes we previously pointed out and are fixed in this release :-)


    Karhu Koti

    Wednesday, October 25, 2017 1:35 PM

Answers

  • Steve did in fact reach out and perform a bunch of debugging.  He said all the issues exposed by the app are fixed now and awaiting a "next release."

    Thanks Steve for all your efforts on this.

    I'll mark this one as answered now.


    Karhu Koti


    • Marked as answer by karhukoti Thursday, February 8, 2018 3:16 PM
    • Edited by karhukoti Thursday, February 8, 2018 3:17 PM
    Thursday, February 8, 2018 3:16 PM

All replies

  • Same error here, is it a UWP  bug, any help ?

    Thanks.

    Tuesday, January 2, 2018 9:52 PM
  • @Francisco_Devia, can you please up-vote this issue (on the left)?

    We are still anxiously waiting to hear back for comments from Microsoft.  We have asked in some other threads to have someone look, but never get any replies back.

    We believe it is a UWP mapping bug.

    Our app clearly shows that lines can be drawn and removed over and over again, but then after a while the app runs out of memory.   We traced it down to the .Add and .Remove of MapPolylines.

    https://www.microsoft.com/store/apps/9WZDNCRDNDF7


    Karhu Koti




    • Edited by karhukoti Tuesday, January 2, 2018 10:13 PM
    Tuesday, January 2, 2018 10:02 PM
  • Hi Karhu and Francisco,

    I am one of the developers on the UWP native map control team at Microsoft, and I have been working for last few weeks trying to repro and analyze if user map polylines have heap issues. So far I cannot repro, but my internal test app might be somewhat different than what users are trying. It would be very helpful if any one has the time to e-mail some snippet of test codes to repro to my e-mail at steseg@microsoft.com

    I have been using RADAR and VS2017's Native Heap profiling to analyze add / remove and modify of user lines, not seeing any glaring heap leaks jump out, there are some overhead costs to simply creating user layers without deleting the old ones, as the layer seems to be more heavy in heap than the elements added to it.

    One thing about my test program is I haven't tried adding and removing polylines to keep 30 around, it should be possible to just make 1 MapElementsLayer and 30 MapPolylines and then change the paths (with SetPath) to actually change the Lat/Long vertices of the polyline and therefore not need to Add/Remove the lines. So I was focusing on that, but re-reading this thread I'm going to try the add/remove also (a single add/remove I have tested and did not find any leaking).

    Thanks for reporting this bug and for using MapPolylines, I hope to get to the bottom of this soon.


    It should not be necessary to flush and/or force garbage collection of the MapControl, the Windows Jupiter layer should manage this memory sufficiently and the underlying native map control should limit its own internal caches to avoid tripping over memory limits. That being said, we have an internal stress tool that hits an out of memory error after about 2 days as well, I haven't discovered precisely why.
    Wednesday, January 3, 2018 8:33 PM
  • Steve did in fact reach out and perform a bunch of debugging.  He said all the issues exposed by the app are fixed now and awaiting a "next release."

    Thanks Steve for all your efforts on this.

    I'll mark this one as answered now.


    Karhu Koti


    • Marked as answer by karhukoti Thursday, February 8, 2018 3:16 PM
    • Edited by karhukoti Thursday, February 8, 2018 3:17 PM
    Thursday, February 8, 2018 3:16 PM