McIDAS-V Support Forums

I've used McIDAS-V beta 1 for about a week now and I'm 100% sure that there is a significant memory leak. This always occurs when using McIDAS AREA files from NCDC (10 MB, covering around 1000 X 15,000 elements), however I don't use other types of data so I don't know if this occurs in smaller files. The memory usage increases when Create Display is selected and the product is displayed, but is NOT freed back to original levels when Edit > Remove All Layers and Data Sources is chosen. Continued image loads and removals increase the memory use substantially until the memory panel begins turning red, then the software stops working and has to be restarted.

In the McIDAS config I have it set to 80% memory usage. When I had 1 GB of memory in the computer, it would rapidly run out of the 800 MB available after only 4 or 5 image loads. When I have 2 GB of memory in the computer, it exhausts the 1200 MB available after about 12 to 14 image loads.

This is the win32 build under Windows XP Pro SP 3, JRE 1.6.

I know how important debugging details are, so I offer this:
1. I start Mc-IDASV. Memory now 67/112/1316 MB.
2. I load an AREA file from Data Explorer and Create Display. Memory now 428/593/1316 MB.
3. Edit > Remove > All Layers and Data Sources. Memory now 200/593/1316 MB.
4. I load another file. Memory now 517/593/1316 MB.
5. Edit > Remove > All Layers and Data Sources. Memory now 531/593/1316 MB.
6. I load another file. Memory now 546/639/1316 MB.
7. Edit > Remove > All Layers and Data Sources. Memory now 559/639/1316 MB.
8. I load another file. Memory now 620/876/1316 MB.

So you can see how clearly usage is spiralling upward.

Tim

Thanks for submitting this report -- I'll definitely look into it. For the sake of being thorough, have you tried clearing the memory and cache explicitly? [ This can be done at any time by right clicking on the memory panel ]

The Java virtual machine may not immediately release its requested memory in an effort to avoid an expensive reallocation, or it may be performing some caching. You can (kind of) force the JVM to perform its garbage collection, but it's not something that should be used often. It causes a performance hit in that the JVM may have to reexamine what memory can be freed, and it'll certainly wipe out any cached objects.

I've tried clearing the memory/cache with the right-click as you described, but it only frees up small amounts of memory, for instance Memory Used might drop from 1120 to 850 MB, but keeps climbing with continued use until McIDAS is no longer usable without program restart.

Tim

Hi, Tim -

Two things:

#1 - Have you confirmed that you have the latest video driver for your graphics card? We have seen strange behavior with memory and CPU consumption when drivers are out of date. And beware, a new machine can have drivers that are 5+ years old.

#2 - Can you send us examples of the AREA files that you are loading, and what process you are using to load them? You can put them on our anonymous ftp site in ftp.ssec.wisc.edu:/pub/incoming

We haven't seen this problem, but may not be using the same methods that you are.

Thanks, Tim! We really appreciate the feedback.

- Becky

I have uploaded an example of an area file that does this into your FTP pub/incoming directory. It's the file that starts with "memoryleak".

If you alternate Create Display with it and Remove All Layers & Sources 5 to 10 times you should see memory consumption increase.

I'll check the drivers (ATI Radeon X1650) in the meantime.

Tim

OK... I upgraded my drivers from ATI Radeon 8.451 to 8.591 (March 2009) and restarted everything, and the problem still exists.

Tim

Hi, Tim -

Thanks for submitting that AREA file. We were having a hard time reproducing your results, but with that AREA file, we can now see the problem as well.

I've created McIDAS-V Inquiry #469, which you can track here: http://mcidas.ssec.wisc.edu/inquiry-v/in ... nquiry=469

Thanks again for letting us know about this. We'll let you know when we find out some more information that might help you with this.

- Becky