JP1 Remotes

[WagonMaster]

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):

[ElizabethD]

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.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[WagonMaster]

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

[vickyg2003]

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.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

[WagonMaster]

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:

[ElizabethD]

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
http://www.hifi-remote.com/forums/dload.php?action=file&file_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
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[vickyg2003]

[WagonMaster]

[gfb107]

I agree that it is a bug in RM.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[WagonMaster]

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]

Try Beta6:

RemoteMaster.v1.98beta6.zip (Windows, Linux 32/64)
RemoteMaster.v1.98beta6.exe (Windows only)
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[WagonMaster]

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]

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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)