10

Bug introduced in 7.0 and fixed in 9.0.0

The functions GeoDirection and GeoDistance have memory leaks. To see this, run the example functions below and watch as the Physical Memory Available in the Windows Task Manager, Performance tab, monotonically decreases with function execution.

memoryLeakGeoDirection[x_] := 
Block[{}, 
Do[GeoDirection[{RandomReal[{5, 15}], 
 RandomReal[{105, 135}]}, {RandomReal[{20, 25}], 
 RandomReal[{140, 155}]}], {x}]]

memoryLeakGeoDirection[10000]

and

memoryLeakGeoDistance[x_] := 
Block[{}, 
Do[GeoDistance[{RandomReal[{5, 15}], 
 RandomReal[{105, 135}]}, {RandomReal[{20, 25}], 
 RandomReal[{140, 155}]}], {x}]]

memoryLeakGeoDistance[10000]

If one swaps GeoDirection or GeoDistance with any of GeoDestination, GeoPosition or Log, Sin, etc. then no memory loss occurs.

I have coded a large Monte Carlo simulation using GeoDirection and GeoDistance. To run the actual simulation it is necessary to call these functions on the order of 108 to 109 times. I have upgraded the RAM from 16 GB to 32 GB, and upgraded from Windows 7 Home Premium to Windows 7 Professional, all in a failed attempt to stay ahead of the leaking memory. I am using Mathematica 8.0.4.0 64 bit.

I have tried $HistoryLength = 0 and ClearSystemCache[], without success in recovering the leaking memory.

Do you have any suggestions as to how to recover this lost memory during a running simulation?

ilian
  • 25,474
  • 4
  • 117
  • 186
Jerry B.
  • 191
  • 6
  • It is not a memory leak, it is a memoization problem. – FJRA Apr 07 '12 at 00:34
  • The example functions evaluate GeoDirection and GeoDistance with a different argument through each pass of the Do loop, and the result is not stored. And yet, memory is still lost continuously as the loop executes. However, memory is not lost in repeated execution of GeoDestination, or Log, Sin, etc. Based on this, it does not appear to me to be a meimonization problem. – Jerry B. Apr 07 '12 at 02:09
  • No, the problem is in the Geo functions, they have the memoization problem. – FJRA Apr 07 '12 at 03:50
  • 1
    I notice the usage with randomreal and this question http://mathematica.stackexchange.com/questions/3682/memory-leak-in-frontend-anyone-know-a-workaround has also memoryleak problems due to randomreal. Would it have the same cause? – Lou Apr 07 '12 at 09:39
  • The memory loss occurs for GeoDirection and GeoDistance. If one replaces GeoDirection or GeoDistance with GeoDestination, Log, Sin, etc., with all else remaining the same, then there is no memory loss, so the memory loss is not tied to RandomReal. – Jerry B. Apr 07 '12 at 17:26
  • How much memory do you lose with the above code? I don't see that much happening. – Sjoerd C. de Vries Apr 07 '12 at 22:44
  • Sjoerd, the memory lost with the above code is about 14 MB for each of memoryLeakGeoDistance[10000] and memoryLeakGeoDirection[10000]. Alternatively, try memoryLeakGeoDistance[1000000] or memoryLeakGeoDirection[1000000] and watch the available memory decline monotonically; in contrast, executing this same code with GeoDirection or GeoDistance replaced with any of GeoDestination, Log, Sin, etc., with all else remaining the same, there is no memory loss. – Jerry B. Apr 09 '12 at 22:27
  • Indeed, I get the 14 MB leak as well. I also get this without RandomReal. a=1.0;memoryLeakGeoDistance[x_] := Block[{}, Do[GeoDistance[{a += .0001, a += .0001}, {a += .0001, a += .0001}], {x}]]. I'll label this with bugs for now. – Sjoerd C. de Vries Apr 14 '12 at 14:08
  • BTW don't forget the @name format if you want to ping someone. Just a name won't work. – Sjoerd C. de Vries Apr 14 '12 at 14:10
  • Could it help to run some bunches of your code in a parallel kernel to localize the memory leaks there, storing the required outputs in the main kernel, and aborting the parallel kernel when it gets too big? – Rojo Apr 15 '12 at 18:01
  • @SjoerdC.deVries Sjoerd, thank you, your code example is better, because you have illustrated this memory loss problem without also calling RandomReal. Thank you for taking the time to investigate my question. If you would, please recommend what I should do to indicate an improvement in the status of my question. – Jerry B. Apr 16 '12 at 21:52
  • @Rojo, yes, I think that this is an excellent suggestion, I wonder how to follow through on this approach. Nominally, the master kernel would always be running, storing the results, and never calling GeoDistance or GeoDirection directly; the slave kernels would need to be loaded with the functions, executed until MemoryInUse[] grew too large, then cleared, then reloaded, etc. – Jerry B. Apr 16 '12 at 21:58
  • @JerryB. Consider registering your account. – Artes Aug 16 '12 at 11:57

1 Answers1

9

Wolfram Research has prepared a patch that eliminates this memory leak. I sent a problem demo notebook to support at WRI, and WRI responded with updated versions for two GeoFunctions.mx files. Replacing the installed GeoFunctions.mx files with these updated patch versions eliminates the memory loss.

I asked WRI if I could upload this patch for others to use, and WRI requested that anyone desiring the patch files contact WRI support directly. They will then provide the patch files and the directions for their use.

Thank you for taking the time to investigate this problem and suggest possible solutions. I admire your contributions to this forum.

rm -rf
  • 88,781
  • 21
  • 293
  • 472
Jerry B.
  • 191
  • 6