RoboRumble/Reported Problems

Actual place to report problem

For server, visit Darkcanuck/RRServer.
For client, visit the tracker at sourceforge.

Please fill bug report instead of this

We are not reading this regularly --Zamboch This is the Tracker

OutOfMemoryError

I'm running roborumble client version 1.5.4 on ubuntu (default VM: openJDK 1.6.0.0), and sometimes in my log I find: Exception in thread "Battle Thread" java.lang.OutOfMemoryError: Java heap space, can someone tell me a way to grab more information about this error or a way to solve it?

UPDATE: found more information

Exception in thread "Battle Thread" java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Arrays.java:2894)

at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:117)

at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:407)

at java.lang.StringBuilder.append(StringBuilder.java:136)

at robocode.io.Logger.log(Unknown Source)

at robocode.battle.Battle.setupRound(Unknown Source)

at robocode.battle.Battle.run(Unknown Source)

at java.lang.Thread.run(Thread.java:636)

--lestofante 12:07, 4 December 2008 (UTC)

To allocate more memory, you need to change "-Xmx256M" in roborumble.sh to something more like "-Xmx512M" or however much you feel comfortable allowing Java to eat. I find 512M is usually a safe value that doesn't run out of memory. --Rednaxela 14:16, 4 December 2008 (UTC)

I've followed your tip but here the another error: Fighting battle 4 ... ags.polished.PolishedRuby 1,jcs.Seth 1.8 Exception in thread "Battle Thread" java.lang.OutOfMemoryError: GC overhead limit exceeded and another: Exception in thread "Battle Thread" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuilder.append(StringBuilder.java:119) at robocode.io.Logger.log(Unknown Source) at robocode.battle.Battle.setupRound(Unknown Source) at robocode.battle.Battle.run(Unknown Source) at java.lang.Thread.run(Thread.java:619) --lestofante 14:38, 10 December 2008 (UTC)

One of my clients also died from an OutOfMemoryError (heap space) while running PolishedRuby against Reaper. I'm using -Xm512, which should be plenty. Most battles run fine so you may have a memory leak? --Darkcanuck 17:48, 10 December 2008 (UTC)

I've looked into my log, the exception are launched only in battle with PolishedRuby.. The bad thing is after this error roborumble will not exit, blocking all external loop script. --lestofante 18:02, 10 December 2008 (UTC)

Yeah, my client also had an out of memory error with PolishedRuby when I came back to the computer now. I find this quite odd because it's gun is an exact copy from RougeDC and the movement doesn't store any data, and yet I've never seen RougeDC get an out of memory error with -Xmx512M. The only possible cause for this I can think of is that certain battles might last longer with PolishedRuby than RougeDC and because the gun consists of a PM and two DC configs memory usage is increased in longer battles. Still though, I doubt battles last that much longer really, so I'm quite perplexed... If anyone knows of any way to profile memory usage, I'm all ears. --Rednaxela 20:02, 10 December 2008 (UTC)

GC overhead limit exceeded exception mean that java garbage collector is working about 98% of application time... try some GC monitor (VisualVM has it) --lestofante 21:17, 10 December 2008 (UTC)

Well, in tests with VisualVM, I can't ever get GC overhead to exceed 20% with PolishedRuby and 10% with RougeDC (RougeDC surfs and thus eats much more cpu), so I'm not sure what's with these "98%" cases, but it does seem that the gun is causing much more GC activity than I'd like. It's looking like it's related to the data structure for the single-tick patternmatcher that's in there. I'll look into it more some time but right now I have a bunch of finals to do. --Rednaxela 09:06, 11 December 2008 (UTC)

I've deleted the old log, but if I remember well the exception is trigged only vs some robot, like jcs.Seth 1.8 (maybe your GC + enemy GC > 98%, maybe a bug trigged in particular condition). Actually this exception freeze my roborumble (switching to version 1.6.0 hasn't help), so I've excluded the bot. --lestofante 17:05, 11 December 2008 (UTC)

Bad results

Darkstorm's client has been uploading some problematic bad results in some cases such as here, and so has Alcatraz such as here. I really think the server should remove and reject all 0% scores where the expected score is greater than 10%... Or just reject 0% scores like the old server did... I really don't trust the scores right now with all those bad results scattered around... --Rednaxela 18:55, 16 December 2008 (UTC)

I gave a brief try at running 1.6.2 beta 2, and the rumble gave all sorts of problems for the new SilverSurfer (post-fix). I promptly switched back to 1.5.4. I'm not sure how Alcatraz and Darkstorm are configuring their client to get the 0 scores on 1.5.4 though. I've played around with the config, and I can only get it to happen on 1.6.2b2. So maybe they upgraded and didn't change their config file? So it still says 1.5.4.... --Skilgannon 21:10, 16 December 2008 (UTC)

What are you seeing happen with SilverSurfer in 1.6.2 beta 2? I just downloaded and installed 1.6.2 Beta 2 and SilverSurfer seemed to run just fine (but I didn't do it in the rumble or give it that many trials). I highly suggest that you report the problems you saw so we won't be stuck with a 1.6.2 non-beta corrupting the rumble... --Rednaxela 21:49, 16 December 2008 (UTC)

stopped roborumble, toworrow i will take a look. edit: yesterday i've renstalled robocode because roborumble gave a

Exception in thread "Application Thread" java.lang.ArrayIndexOutOfBoundsException: 0
	at roborumble.battlesengine.BattlesRunner.runBattles(Unknown Source)
	at roborumble.RoboRumbleAtHome.main(Unknown Source)

--lestofante 22:21, 16 December 2008 (UTC)

I get that same error in 1.6.1.4 here, but it seems harmless as the results uploaded from my client are still correct, so I'm quite sure that's completely unrelated. --Rednaxela 23:06, 16 December 2008 (UTC)

Just a tip (that probably all of you know) when starting with a new client version: set UPLOAD=NOT in your roborumble file, let the client run for a while, and then check the results in your resultsfile. When bad results are there, discard the file and start using your 'old' client again. --GrubbmGait 06:23, 17 December 2008 (UTC)

I didn't run any rumble battles on 1.6.2 beta 2, but I had problems with it, they seemed minor problems, like the paint feature doesn't quite work, and when a bot skips turns then is a pain to reload the same bot. But it didn't look stable enough for rumble battles for me. --Zyx 04:59, 19 December 2008 (UTC)

I'm pretty sure "when a bot skips turns then is a pain to reload the same bot" has always been the case. For me anyways that has always happened. As far as painting issues, well, report them! :P
What worries me are the SilverSurfer issues that Skilgannon mentioned that I couldn't reproduce and I think would be important to report. Oh, also Speaking of the 1.6.2 Beta2 version, Beta3 was just released today, so testing should probably be on that version --Rednaxela 05:29, 19 December 2008 (UTC)

Wrong Participant list

Er, Skilgannon it looks like your client is using the wrong participants list (and not this wiki's one either) because it's uploading DrussGT 1.1.1. --Rednaxela 22:59, 16 December 2008 (UTC)

Yep, I started another client and it had some 1.1.1 left in the results file. But now it is trying to fill up the pairings for it, why I have no idea. My other client is behaving normally. I'll clear all the temp files... and Darkcanuck], could you re-enable removing bots from the rumble? --Skilgannon 06:28, 17 December 2008 (UTC)

Sorry, been away for the past few weeks and my "home" client went down. Old bots have been removed and I'll look at opening up removals again in the next few days. --Darkcanuck 23:40, 28 December 2008 (UTC)

Hey no worries. Thanks for all you've done with this RR server! --Rednaxela 06:19, 29 December 2008 (UTC)

I think the wiki is down again, may be there more old problem about removing every tobots :) -- Nat 06:16, 30 December 2008 (UTC)

Hey, why the old wiki content reseted? I need to re-enter my robot to roborumble! --Nat 12:57, 6 January 2009 (UTC)

Robocode 1.6.0.1 - teamrumble

I'm running robocode 1.6.0.1, windows XP 16bit, java 1.6. When I try to run teambattle my client simply freeze without error during the first battle. Someone else is having this kind of problem? --lestofante 12:52, 14 January 2009 (UTC)

No. I also run robocode 1.6.0.1 on Windows XP and java 1.6 and... What, how can Windows XP be 16 bits?? But I don't have that problem. My client run well. --Nat

Client doesn't want to proceed battles

Hi, I'd like to restart contributing battles but my client doesn't want to proceed battles after downloading the participant list. Here is my roborumble.txt: [1] Please show me what's wrong with it. I use 1.6.14. --HUNRobar 18:21, 14 May 2009 (UTC)

• My PARTICIPANTSURL starts with testwiki.roborumble.org, that is the only difference I found that matters. Do note however, that after upgrading your client version (or moving your directory) you should clean your .robotcache, and rebuilding it will take quite some time. --GrubbmGait 08:36, 15 May 2009 (UTC)
• Your client just hangs without an error message? Also make sure that you've edited roborumble.bat (or .sh) to give java at least 512M heap space because the default is too low (fixed in newer versions) -- if it's too low your client may freeze up. And before running the client, run robocode.bat/sh to make sure your installation works and set the CPU constant. --Darkcanuck 14:39, 15 May 2009 (UTC)
• It may be that it's building the .robotcache and taking a long time to do so. Try just running Robocode (like Darkcanuck said) and seeing if it loads up OK. --Voidious 15:15, 15 May 2009 (UTC)
• Ok now works. :)--HUNRobar 15:45, 15 May 2009 (UTC)