Global Mapper v25.0

Is this a memory leak?

I was reporting stability issues in this thread - http://forum.globalmapperforum.com/discussion/13403/raster-export-stability-issues#latest - where the program is constantly crashing while downloading imagery.

The most stable behavior I can get is running 32 bit version with XP compatibility. I am still getting these crashes even with this configuration - it is random and I can't establish a pattern but I can see that the program does start using large amounts of memory - beyond what is should be for what it is doing - before it then crashes. In one of the images I have attached you will see 3 instances of GM running. They are all doing the same thing - downloading imagery. All it is downloading is from a square selection - 15,000 x 15,000 tiles, no vector information and nothing else to do but download tiles. 2 of those instances were running fine They only peaked at around 1.8 Gb. The instance that has crashed had peaked at 3.3. In the image memoryleak3 - you will see that it peaked out at 3.8 Gb (I am not sure if these even should be possible on 32 bit version).

Are those huge amounts of memory consumed that don't occur all the time but do always cause a crash, memory leaks?

Anyway - to summarize - program can be unstable during downloading and often crashes. The only pattern I can establish is that when it does crash it has consumed a lot of memory. It is not the fact that I am using the 32 bit version because I get more unstable behavior with the 64 bit version.

Any chance for a fix?? I know you are not responsible for the imagery servers - but the issue does only ever happen when downloading and while issues might originate from the server, what could be originating that is causing the program to start to consume huge amounts of memory and then crash? And therefore what can be fixed? I do find that most (but not all) crashes happen when downloading from the World Imagery server - but I am downloading from there the most.

Thanks.

Answers

  • bmg_bob
    bmg_bob Global Mapper Programmer
    Hello,

    Your best bet to resolve this issue remains to continue communicating with Blue Marble Geographics Support (geohelp@bluemarblegeo.com).  Since you are having problems exporting data form an online source, it would be helpful for you to send a workspace that contains the definition for your download.  This will make it easier to reproduce your problem, and will expedite a solution.  Thank you.

    Cheers,

    Bob

  • Thanks. Right now I don't have time to communicate directly with your support. I will try for next week. I have finally established though that it is a case of my running out of memory even on a 12 Gb system. The 32 bit version kept crashing on the workflow I will describe below (peak memory use was 3.8 Gb then it crashed.) so I went back to 64 bit version. It stopped crashing. I checked the peak memory usage and it peaked out at 7.4 Gb during downloading of files. That's why the 32 bit version was crashing (it was needing to use 7.4 Gb which it couldn't of course).

    My workflow was simply this. State of NJ download at 0.59 meters per pixel. I created a grid of around 380 tiles of around 9 km x 9km (15,000 x 15,000 pixels). Exported so that each square was a tile. These end up being about 1 Gb per tile (uncompressed). I am exporting as GeoTiff, 24 bit, LZW compression.

    What I have found that during download as it builds each tile in the temp directory the memory usage goes up dramatically up to around 7 Gb, Once it has created the file it drops again. There is a pic attached showing that.

    What I can't understand is that on some downloads I run, the program downloads directly to the file and bypasses using the temp directory so you can see the file size increase as the download progresses. Then in some downloads I run it does use the temp directory to build each file.

    Now what I ultimately discovered is that when it uses the temp directory memory use goes up dramatically as described above. When it downloads directly to the file and bypasses using the temp directory memory use is very low and it rarely goes above 1 Gb. So when does the program decide whether to download direct to the file or use the temp directory? You probably need to take a look at why building the file using the temp directory method uses so much memory. The math says it should not have to use 7.4 Gb of RAM to patch together 4 X 250 Mb subtiles into a 1 Gb tile.

    The good news is that the program no longer crashes!!!! All I have to do now is increase my swap file size and I shouldn't have any more problems. You have definitely addressed the stability issues I reported a few weeks ago. Thanks.