RoboRumble/Reported Problems

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)

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)