ThinkGeo.com    |     Documentation    |     Premium Support

Memory leak in latest ThinkGeo UI WPF versions

#1

Hi ThinkGeo,

We have noticed ThinkGeo 13.2.0-beta022-40 have an issue which causes memory not to be freed and it eventually crashes the application. It came up when taking a newer ThinkGeo UI WPF version in use.

The problem has something to do with removing and re-adding layers and simultaneously calling MapView.Pan(). This happens in our application when logging out and logging in another user. Maybe relates to the late addition of async methods.

Best Regards,
Jarno

#2

Thanks @Jarno_Kalliomaki,

We’ll take a look and try to recreate it. I will see if I can recreate the issue on my side. By any chance do you have a pared-down sample showing the issue that you could zip and email to support@thinkgeo.com? That would save a lot of time if you’re able. These types of memory bugs can be hard to recreate.

Thanks,
John

#3

Hi John,

Unfortunately we don’t currently have the issue visible on a test sample. But here’s a screenshot from a diagnostics session which might be useful. And just to be clear, on beta021 we haven’t seen this kind of memory usage increase.

MemoryIncreaseWhileDrawing
MemoryIncreaseWhileDrawing2129×534 56.2 KB

Best Regards,
Jarno

#4

Hi Jarno,

I see in your screenshot above, the memory went up around 50 seconds but then at 57 seconds it was all garbage collected and memory returned to normal. Is that what you experienced, or are you seeing the memory stay abnormally high?

Also, if you’re unable to provide a sample can you help me with what types of layers you have on your map and how often you trigger the mapView.Pan() function? Or maybe some pseudo code of the simultaneous removing and re-adding? I’m just trying to find a way to recreate what you’re seeing.

Thanks,
John

#5

Hi John,

Yes the memory consumption does eventually come down but usually our application crashes because it simply runs out of memory and not able to function properly anymore. We are talking about tens of gigabytes so it’s not good.

I quickly debugged which layers we have by default loaded:

  • 1 ThinkGeoCloudRasterMapsLayer on ThinkGeoCloudRasterMapsOverlay
  • 5 empty LayerOverlays
  • 2 LayerOverlays with 1 InMemoryFeatureLayer
  • 2 LayerOverlays with 2 InMemoryFeatureLayers
  • 1 LayerOverlay with 5 InMemoryFeatureLayers

Most of the layers contain some simple raster graphics. For example gps location indicator.

I think the Pan() function and also Overlay.Refresh() might get executed several if not dozens of times in some occasions. For example during log in or log out operations.

I hope this helps. We will also continue investigating if we can change something our side.

Thanks,
Jarno

#6

Hi @Jarno_Kalliomaki,

I’m not sure if I’ve recreated the same issue as you, but I have seen some instances where memory on the latest beta build is higher than early 13.2 beta builds.

I’ll elevate this to the product team.

Thanks,
John

#7

Hi @Jarno_Kalliomaki,

  1. We fixed a memory issue John found in ThinkGeoVectorTileView, but I didn’t see memory leak in ThinkGeoCloudRasterMapsOverlay or LayerOverlay.

  2. We reduced the potential memory pressure by drawing the overlays one by one, instead of drawing all the overlays at the same time.

The above 2 changes will be in the daily build (the latest 13.2.0 beta branch) tonight.

A couple questions for you:

  1. what do you mean by “We are talking about tens of gigabytes”, do you mean it consumes 10g+ of memory by just using ThinkGeoCloudRasterMapsOverlay and several layovers?

  2. are you using x64 or Any CPU for your application, or x86? X86 has a 3g memory limitation but x64 should not.

Thanks,
Ben

#8

Hi @Ben

Thanks for letting us know. We’ll be looking into this on the later versions at some point when we try to start using the new async methods. For now we are looking at a minor upgrade wall.

To the questions…

  1. That’s right. I think we’ve seen over 20GB for the process at some point before crash. Maybe some random GeoTiffRasterLayer has been in the mix too but basically as you say.

  2. Yes, we are on an x64 platform so memory consumption this high is not impossible to handle in that sense. I think the hardware is nearing it’s limits though as it starts to go in to the swap file. Especially when the memory reservation happens within seconds.

Best Regards,
Jarno

#9

Hi Jarno,

I see. I didn’t see memory leak but rendering multiple overlays at the same time could bump up the memory a lot in a short time, depending on the data size in those overlays. Please play with the latest version when you have a chance and let us know.

Thanks,
Ben