The Bug:
Under JRE 1.4.2.x, Any bot trying to access data from the disk "gains" eventually a SecurityException? that disables the bot even if it's (the Exception) caugth.
It's a Bug?
Since it was working and now ain't no more...
So what do we do?
There is a possible solution posted at MSWindows page:
There is a work around that has been posted for the file saving issue that applies to at least JDK 1.4.2_02. Install and chage the batch scripts that start any Robocode instance by adding "-Dsun.io.useCanonCaches=false" (ie: java -Dsun.io.useCanonCaches=false -Xmx256M -jar robocode.jar). I have tested file savings with Roboleague, Robocode, and RR@H and they all seem to work (no Exceptions reported so far). -- Sparafucil3 (i think...)
Now if we could figure out that old Serialization problem Paul had on the RR, we'd be set (think this would do it?) -- Kawigi
Robocode was reporting it as a "Security Exception" because as far as it was concerned you were trying to write a file outside of it's sand box. If you follow the link on the RobocodeRepository regarding this you will find that whats happening is that the JVM is having a hard time providing the correct file name (I specifically think it is having a hard time with mixed case words). Your bot then tries to write to a file that Robocode does not know about so it raises a security exception. If Paul was serializing to disk then I would be that this is the same issue he was having too. -- jim
No - the serialization problem I had/have was communicating between bots in a team - I could serialize to file ok. but in order to send messages between bots reliably I had to covert a byte array to a string to send the message (and reverse the operation when recieving). I think it was a hi/low byte probelm but there is a workaround. -- Paul Evans
Yeah, so if it's purely a matter of file I/O, it probably doesn't help, because I think team messages just get serialized and deserialized through piped I/O streams. -- Kawigi
I forgot to mention that with RoboLeague I needed to modify the launcher.properties file. I changed the line user.cmdline= to user.cmdline=-Dsun.io.useCanonCaches=false. I think this file specifies properties to the launch of the robocode engine that it uses. Sorry about that. Also, RR@H still managed to freeze last night but it was after 50 iterations, which is 4 times more than I have ever managed to run before. -- jim
I modified my batch file as explained above, I'm using java 1.4.1, and I *still* get this bug. Help! Is there anything else I can do as a person who runs the RR@H client to stop this? Is there anything I can do as a bot author to prevent this bug from affecting their ratings? --David Alves
Did you modify the batch script that starts RR@H too? I have not had this problem except with bots that get downloaded by the RR@H client after it has been running. I think I have read elsewhere that this is an issue that Albert is aware of but can not fix. The only solution at this time is to restart. If the batch script were modified to restart if java stops a System.exit() could be added if anything is downloaded and then you should not see this anymore. -- jim
As a recent data saving bot author I took the extra effort to minimise the effect of this bug by only loading/saving files in the first and last round. For a very long time I ran the RR@H client without the bug workaround because I used java 1.3 in my main testing computer and wasn't aware of the implications of this bug. Anyway, the playing field is even, until there is a defenitive solution you'll have to weight the pros and cons of data saving. -- ABC
ABC, if I load data at the end of round one after I've already won or lost, will that affect my score? --[[David Alves]
No, it won't. You will get disabled but your score will not be affected. One of Shadow's latest versions did save at the end of every round. It may affect your opponent's score tough, because any bullet still in the air is a potential kill for him. -- ABC
if you are silly (like me) and copy/paste the above fix, then don't forget to get rid of the ? generated by the Wiki engine :D ...... --Vic
Anyone who finds Vic's remark peculiar should know that I have removed the questionmark he's talking about. =) -- PEZ
There goes my joke ;-) --Vic
Where do I add this fix for the RR client? In roborumble.bat? --Vic
Yep. Just add "-Dsun.io.useCanonCaches=false" in any of yours .bat... Here is my roborumble.bat:
cd robots :run java -Dsun.io.useCanonCaches=false -Xmx256M -cp .;../robocode.jar;../codesize.jar; roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt goto runIt would be a good idea if the clients already had this... -- Axe
Ok, thanx. --Vic
Does this happen in 1.5? --David Alves
Good question. donīt know... -- Axe
Downloaded and tested JRE 1.5 here. The result is even worst with it. It seems to happen 100% (10/10). So, the bots accessing files are geting disabled at least one round in JRE 1.5...
The "-Dsun.io.useCanonCaches=false" works fine and correct that issue also for 1.5. @ALL: PLEASE UPDATE YOUR ROBORUMBLE.BAT FILES TO INCLUDE THE "-Dsun.io.useCanonCaches=false". -- Axe
Tested a lil better here, and it isnt 100%, but only eventually that it happens with JRE 1.5.
But happens.
Since i have no control in foreignīs .bat configuration, I have implemented a radical solution: a pull-the-pin-and-swallow-the-grenade strategy, idea inspirated in Jonathan (credits to him). If SS is disabled trying to read data in the first round, it will activate a self-destruction mechanism, and self-disable in all other rounds also. Im counting on the server rejecting those 100% scoring that the enemies will get in this match.
So, if SS is getting disabled in your client, please update your roborumble.bat file as above. -- Axe
Why don't you just stop reading and writing data? It must be less error prone than the above strategy. A strategy which reminds me of those Worms I used to play so much on my Dreamcast. =) -- PEZ
Because i think that data saving and mining can be also a valuable and valid strategy, and (mostly important:) im not prepared to throw away all my beautyfull data compression :). (I never played Worm, so i cant say about it...) -- Axe
But i can say that remembers me the Orson Scott Card book "Enderīs game"... If u havent read, u should (Vic agree, right?)... -- Axe
Thats enought for me. :) -- Axe
@Axe: Have you tried wrapping the save in a try catch and simply catching the error rather than self destructing? Seems like this would at least allow you to continue. I feel the same as you do about saved data but I think your approach is a little too radical and runs the risk that you get a really poor score. -- jim
Self destruction seems risky. Particularly when I constantly question why the ... the server is disregarding shut out battles anyway. -- PEZ
@Jim: that SecurityException? even if it is caught disables your bot. (But if u know how to catch it without disabling the bot, pls tell me). @PEZ I think that one of the reasons for the server disregarding these results is to protect ranking against clients malfunction. At least thats my assumption... -- Axe
In what way could a client malfunction that would cause a shutout result? And couldn't the RR client itself set that environment option in run time instead of relying on the .bat file to do it? If someone looks at that I could tweak the server to accept results only from clients updated in this way. -- PEZ
Btw: I never said that this self-destruction is the best solution. The best solution is to have properly configured clients. But that is obviously out of my control... This is the only solution that i found. If someone come with other solution, ill be very gratefull. -- Axe
Hmmm, I think I just proposed a solution? -- PEZ
I posted it in a edit conflict... That solution of yours is great. But how to assure that everybody is running the "good" client? -- Axe
I mean: this is the same solution of including it in the .bat. If everybody include it... -- Axe
Well, when the results are uploaded the client gives a version number. I could just make the server require the client to use a different version identifier than it uses today. That's the easy part. The tricky one might be to find out and implement the setting of that environment option at runtime.
If you trusted everyone included the .bat change then you wouldn't make your bot swallow a granade with the pin pulled out, would you?
-- PEZ
Bullīs eye! -- Axe
But it would be enought for me if everybody says that their environment are ok, an if we include this in the downloadable clients... -- Axe
OK. But I know that I, for one, was bloody sure I was using that command line option in my clients. Until I checked yesterday. And I wasn't in the most often used one. Of cousre I do now, but anyway. -- PEZ
If you want to check if your robot is going to be disabled when reading/writing to the file system use the following code...
![[Home]](/images/RoboWiki.png)
boolean willMyBotBeAbleToSaveFileInformation = false;
try {
willMyBotBeAbleToSaveFileInformation = (System.getProperty("sun.io.useCanonCaches")).equals("false");
}
catch (Exception ex) { }
It works fine on Java VM 1.6.0 and should work with earlier versions.
A slightly different version that ought to fix the problem (if executed before any reads or writes) is the following...
boolean willMyBotBeAbleToSaveFileInformation = false;
try {
willMyBotBeAbleToSaveFileInformation = (System.getProperty("sun.io.useCanonCaches","false")).equals("false");
}
catch (Exception ex) { }
This sets the default value if it finds none set and can be executed multiple times without disabling any robot. The only problem could be if the flag were set to true when starting the VM - in which case the boolean value would be set to false.
--EventHorizon?