[FIXED]RM "OutOfMemory" Error When Viewing Remote

WagonMaster · Post by **WagonMaster** » Fri Nov 20, 2009 6:14 pm

While testing all the new map/image files with RemoteMaster (RM) for the upcoming new release of RDF/map/image files, I've discovered that it can run out of memory once I've viewed enough different images on the "Layout" tab.

Essentially, I start out at the 1st remote control, scrolling among all the remote images as I check for any errors. Somewhere about 80% through the list, I eventually get this message in 'rmaster.err' and odd things start happening (long bursts of 100% CPU usage, buttons drawn with no backing image, etc):

Code: Select all

Exception in thread "AWT-XAWT" java.lang.OutOfMemoryError: Java heap space

It's pretty obvious when it happens (even without watching the 'rmaster.err' file) because the CPU spikes to 100% for a noticeable time and the background image disappears and all you see are the "orange" button outlines. At that point, every switch to a new remote takes an unusually long time (2 or 3 seconds at best, with a big CPU usage spike, rather than the usual fraction of a second). It's like the images are being cached and once you load enough of them, the memory is exhausted.

BTW, this is running RM v1.98-beta5 under Linux.

Note that I'm running with the (unpublished) full set of RDF/map/image files from the upcoming new release. To give you an idea of the count, the current release (1.28) of the map files has 183 images while my upcoming release has 228. Note that the Kameleon remotes' images (where we have several images for the same remote) are part of those numbers, essentially screwing up the metrics, but that will give you at least a rough idea of the difference in number of images between old and new releases.

Can anything reasonably easy be done to eliminate this problem?

Bill

Post by **ElizabethD** » Fri Nov 20, 2009 6:43 pm

In Windows XP no such issues.
I just walked through 1/2 of the images using RM 1.97, cpu usage didn't move (0.75%), pek memory use for javaw.exe has'nt moved from 61meg. Just so you know where Windows stands.

WagonMaster · Post by **WagonMaster** » Fri Nov 20, 2009 7:06 pm

Thanks for the input, Liz.

However, if you're running through just 50% of the images that came with v1.28 of the map/image set, you're probably not going to see it. I have to go through roughly 80% of the new set (which is meaningfully larger than the last set) before I see any symptoms whatsoever. It's possible that even running through 100% of the v1.28 set would not trigger the problem, but I really should try that, now that I think about it.

I haven't looked through the RM code and I don't know much about tweaking Java settings, but when this occurs, it looks more like a Java and/or RM issue than anything to do with the operating system. At the OS level, I have memory to spare when this occurs. AFAICT, it's just Java that's exhausting its heap.

But your data point is still useful, just in case I'm way off base, which is certainly possible.

Bill

Post by **vickyg2003** » Fri Nov 20, 2009 7:10 pm

Elizabeth, I think you may have stopped too soon. I'm on Win2k, and I wasn't seeing anything until I was about 80% through with the list. I made it up to the producer before I had problems. Just to make sure it wasn't a specific jpg, I made my next run through starting at zap station and working backwards. I made it back to "Force V4 39722" before RM came to a grinding halt. I wasn't watching CPU usage, but there is definately about an 80% limit on the remote range that I can step through. Fortunately I don't ususally try to scroll through all the remotes one by one. My normal usage is to pop open RM to look for 1 specific remote.

WagonMaster · Post by **WagonMaster** » Fri Nov 20, 2009 7:50 pm

Update:

I realized that I cannot run a meaningful test of the old 1.28 set of maps/images under Linux because of all of the case-sensitivity bugs that have been lurking for years in the map/image/RDF files.

So, instead of that, I drug out a laptop and fired up WinXP-SP2 and proceeded to scroll through the images from the "Layout" tab. Initially, I was pointed at the (smaller subset of) v1.28 images/maps. No problems -- I made it through every image.

Then I installed the "new" set of RDF/map/image files, pointed RM to that set and, sure enough, it acts up the same way on WinXP as it did under Linux (but it takes a few more images to get to that point, it seems).

In other words, even under WinXP, running RM 1.96, I can get the image to disappear, only showing the button outlines. What's weird is that, unlike Linux, where there's a burst of CPU activity and then RM is functional again, under WinXP, it totally hangs up the RM application -- I let it sit for several minutes and was never able to regain control! I had to kill the Java task.

But the 'rmaster.err' log on WinXP shows the almost-identical error message as Linux:

Code: Select all

Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Basically, there are a few variants of ".... java.lang.OutOfMemoryError: Java heap space" messages in the log.

So clearly there's a problem that's not OS-specific here.

Vicky, thanks for running the test. I'm guessing that you may have more RDFs/maps/images than the set that comes with v1.28 because I had to switch to the new (larger, unpublished) set before I saw problems.

Bill

Post by **ElizabethD** » Fri Nov 20, 2009 8:43 pm

OK. I see a problem, if we really insist on calling it a problem.
About 60-70% up from the bottom (I started at the end and went up the list), RM had enough. Good thing, I did too

RM was not really designed for image trips such as this.
That said, I collected a bunch of process explorer data, which might be showing a jawav memory leak between when I did 50% files and when it crapped out. But I don't know how to interpret such things really.
Error log included in this zip
https://www.hifi-remote.com/forums/dload ... le_id=7510
Please review in chronological sequence by time.

Errors that I see are
Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

RM1.97, WindowsXP-home-SP3, RDFs 1.28

Post by **vickyg2003** » Fri Nov 20, 2009 8:50 pm

Elizabeth wrote:
OK. I see a problem, if we really insist on calling it a problem.
RM was not really designed for image trips such as this

Yeah that's my thinking too. It wasn't meant to be an image scroller. I look up pictures in RM all the time, but I never try to visit each and every one.

WagonMaster · Post by **WagonMaster** » Fri Nov 20, 2009 9:17 pm

vickyg2003 wrote:
Elizabeth wrote:
OK. I see a problem, if we really insist on calling it a problem.
RM was not really designed for image trips such as this
Yeah that's my thinking too. It wasn't meant to be an image scroller. I look up pictures in RM all the time, but I never try to visit each and every one.

No disrespect meant to Greg or the Java language folks, but an uncaught heap overflow, whether it locks up the app or not, is a bug in any language/application. I don't know if this is a Java bug or an RM bug, but it is a bug. If the user interface allows the operation and it can crash the app, that's a bug/problem!

By the way, it's a lot faster to test this without using the mouse, in case you're doing it with click-click-click, Liz. The arrow key is your friend.

Bill

gfb107 · Post by **gfb107** » Sun Nov 22, 2009 6:29 pm

I agree that it is a bug in RM.

WagonMaster · Post by **WagonMaster** » Sun Nov 22, 2009 9:20 pm

Greg, your post reminded me to search the Internet for some way to control the heap size in Java.

I turned up a set of command line switches that set the iniitial ('-Xms') and maximum ('-Xmx') heap sizes.

I also tweaked the RM code to display the initial heap size (without using any command-line switches) and found that it came out at about 13MB.

I used "-Xms40m -Xmx65m" for initial/maximum of 40MB/65MB. But RM exhausted heap and started acting weird when I got through about 80% of the remote control images on the "Layout" page.

I tried "-Xms40m -Xmx100m" and was able to successfully scroll through all of the images without any odd side-effects or heap overruns.

So there's a reasonable work-around to this problem. Since we agree that this is a bug, for my 2 cents worth, it seems that a simple (?) check to just bail out gracefully when the heap is exhausted with some sort of message in the error log would be all that's needed. No need for anything fancy, IMHO.

Bill

gfb107 · Post by **gfb107** » Fri Nov 27, 2009 9:58 am

Try Beta6:

RemoteMaster.v1.98beta6.zip (Windows, Linux 32/64)
RemoteMaster.v1.98beta6.exe (Windows only)

WagonMaster · Post by **WagonMaster** » Sat Nov 28, 2009 1:50 pm

I've now tested with the RM 1.98-beta6 and this problem is gone -- thanks!

However, it seems that the RM/RMIR source code is not being updated. I sometimes need to compile my own version (as done recently when testing the problem in this very thread), so I'd really like to see the SourceForge repository updated too. Is there some reason why the source code is stale?

Also, if there are going to be so many beta versions released in between major versions, I'd humbly request that the source code be tagged appropriately (i.e. with a 'v1_98_beta6' tag) so that one can go back and pull/build an older beta version for customized testing. If there were just a few quick betas released over a short time span (e.g. a week), I really wouldn't care about identifying beta builds, but it's been a long time since the last official release and that's making beta-tagging more important, IMHO.

Also, still assuming that there will be longer times between official releases, it would be helpful if the changelog identified what was fixed in each beta version, instead of having them all grouped under the "Changes for v1.98" title. You could always merge all of the 'beta' changelog comments into a single section when you release the final version. Not a show-stopper issue, but it helps to know more precisely what I should be testing most thoroughly with each beta release.

Bill

gfb107 · Post by **gfb107** » Tue Dec 01, 2009 8:30 pm

Sorry I didn't see this before. I have very little time to spend on JP1 and RM/RMIR. And that's my primiary excuse for not checking in the source along with each beta and creating a tag to go along with it.
The reason all the releases have been betas recently is because I haven't had time to test them adequately, but the fixes were important enough that I felt they should be available for those who need them.

The only other excuse is just that I'm not in the habit of doing it, simply because there's been very, very few times in the almost 6 year history of RM/RMIR that anybody but me has had any use for the source code.

Of course neither of those excuses justify it.

I'll try to do better.