Editing revision 49 of JRE 1.4.2 SecurityException Bug

Robo Home | Changes | Preferences | AllPages

Editing old revision 49. Saving this page will replace the latest revision with this text.

This page was created in order to organize the info about this bug, since it's all spread around this site.
You can find people talking about it in:
[[RoboRumble/ReportedProblems]] 
[[CompressedSerialization]] 
[[MSWindows]]

----

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 <code>"-Dsun.io.useCanonCaches=false" (ie: java -Dsun.io.useCanonCaches=false -Xmx256M -jar robocode.jar)</code>. 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. -- [[Sparafucil3|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 <code>launcher.properties</code> file. I changed the line <code>user.cmdline=</code> to <code>user.cmdline=-Dsun.io.useCanonCaches=false</code>. 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. -- [[Sparafucil3|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 <nowiki>"-Dsun.io.useCanonCaches=false"</nowiki> in any of yours .bat... Here is my roborumble.bat:
<pre>
cd robots
:run
java -Dsun.io.useCanonCaches=false -Xmx256M -cp .;../robocode.jar;../codesize.jar; roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt
goto run
</pre>
It 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 <nowiki>"-Dsun.io.useCanonCaches=false"</nowiki> works fine and correct that issue also for 1.5. @ALL: PLEASE UPDATE YOUR ROBORUMBLE.BAT FILES TO INCLUDE THE <nowiki>"-Dsun.io.useCanonCaches=false"</nowiki>. -- [[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]]

[[Paul]] agrees also. -- [[Paul]]

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]]
* Thanks... -- [[Axe]]

Summary:
Consciousness check: 2 * 11 =
This change is a minor edit. Send email notification that JRE_1.4.2_SecurityException_Bug has been changed.
(Visit Preferences to set your user name.)

View other revisions
Robo Home | Changes | Preferences | AllPages