|
Good news! I think I have a fix for this! I'll post it with my UI improvements at OpenSourceRobocode/Contributions, and I'd appreciate anyone with a multi-proc or HyperThreading machine that has hit this before to re-enable it and test it out for me (and anyone who writes robots to try my new editor enhancements)! -- Kawigi |
What version of Java are you using? I haven't done any extensive testing lately, but I think I've had a lot less crashes since upgrading to 1.4.2 (from 1.4.1, IIRC) (I'm using XP) -- Tango
I'm running every bloody version of Java from 1.3.1 and up I have been able to find. And it's not crashing. It simply freezes, stops, does nothing. -- PEZ
Is it still using CPU cycles? -- Tango
I run 2 XP PCs, one with java 1.3 the other with java 1.4, and don't have any problems at all. At work (java 1.4) I usually leave the pc running the roborumble for over well 48 hours without a single crash, and at home (java 1.3) I don't remember the last time I saw RC crashing... Have you aplied all the latest MS patches? DirectX? and OpenGL combined with some graphic cards can sometimes be a pain... -- ABC
Yes, it's patched to the last patch. I'm suspecting a graphics card conflict of some kind (bacause Sun talks about that and Java freeze problems). But I have a Radeon card in this PC at home and a GEForce in the PC at work so it might not be that... The search continues. =) -- PEZ
I'm using XP also (with java 1.4.1) and have no problems at all. -- Albert
Well, there seems I might not be the only one though. I will try some of the things suggested on this page: http://java.sun.com/j2se/1.4.2/relnotes.html#2d and see if it might help. When robocode is running minimized I shouldn't lose any performance by disabling Direct 3D I think. -- PEZ
OK, so none of those flags helped on my work PC. Maybe it can make a difference at home... -- PEZ
I hadn't tried version 1.4.0 actually. Now I am doing that and the RoboRumble@Home client is on iteration 5 now. I think my record has been 6 iterations. I'll leave it on over night and if it runs when I come back tomorrow I'll declare that using Java 1.4.0 has fixed my problem. -- PEZ
I have missed to answer Tango's question there above. No, when java freezes on me like that it also stops using CPU. -- PEZ
This is depressing. The 1.4.0 trick doesn't work on my home PC. However it seems on this machine the freeze happens only with certain bots. Shadow causes the freeze within 20 rounds. Any of my recent bots seem to be able to run forever. As does FloodMini. Raiko freezes the java within some 100 rounds... Yuk! Raiko and Shadow happens to be my favourite test bots... -- PEZ
Maybe you have a memory problem (faulty ram). I don't know about Raiko, but Shadow uses lots of memory (maxing out at around 50-70 rounds). Have you had any problems with other aplications? Recent games are usually a good hardware test... -- ABC
I know your feelings on GUIs, but try the GUI I linked. Hopefully I didn't break anything in the last bit of fiddling, however in the past it's Safer Iteration option has greatly increased the stability of RR@Home. Because it's entirely seperate from the RR@Home client I was able to let the java process it's in quit entirely and start a new one as my form of iteration. If you set the RR@Home client to not iterate and the GUI to iterate it'll run slower (due to that first battle startup time) but should be extremely stable. If you set RR@Home to iterate as well as the GUI to iterate it'll act as automated crash recovery. If you look in the source code for OutputFrame? you'll find the code for this and can make yourself a nice little command line wrapper client for the same behaviour. -- Kuuran
My feelings on GUIs? =) I don't mind GUIs in fact. (But I am also very fond of CLIs.) I will definately try the GUI wrapper on the client. I like that it runs the client in non-iterating mode. However, I somehow doubt it will help for my current problem. What does the GUI do when one of it's spawned iterations just freezes? Rememer, Robocode doesn't crash, just freezes. WindowsXP doesn't seem to see that the process is not working. At least the process viewer doesn't show any indication of that. I have switched on every single column... Also, even though I can't run 50 rounds vs Shadow in the Robocode environment the RR@Hclient chewed on the entire night. I don't know if it ever got to excerice the Portguese master piece, but I would guess it did since the machine must have run thousands of pairings during the 6 hours or so it was working. It was only the usual crashes when Ender was up in the ring. (Which makes me think we should remove that bot from the rumble.)
On the issue of memory. It feels strange that I should be so unlucky that both PCs I happen to have access to should have faulty RAM. Sure, I am lucky in love, but ... Both machines have 1GB of RAM though. Could this be a clue? Maybe java under some conditions on WindowsXP does something funny when the RAM is plenty? I did try to run the chipset of my home computer in the safest mode. But it doesn't seem to help. Is there some other way I can test the memory other than buying a recent generation game? I think Battlefield 1942 looks way too interesting to dare buy it. That could seriously impact my bot development. =)
-- PEZ
You don't need to GUI for that fix. The batch file that runs the client on my PC (IIRC it was the default file) has an infinite loop it in, so whenever the client crashes it just loads it up again. Not that that would help if its just freezing, rather than crashing.
Having a lot of RAM could be the problem, maybe Java can only access the first X MB of RAM, but sees that there is 1GB there, and gets confused (eg. fills up all its RAM, and then tries to keep going). Windows Process viewer has a memory usage column, which could help you track that down.
-- Tango
Well, it doesn't show anything peculiar with the memory usage. Robocode doesn't seem to use all that much memory either. Some 22+ MB. 45+ MB when Shadow is running. -- PEZ
Hrm, Tango's probably right.
Like Windows the GUI can't tell, there is a kill button that attempts to terminate the process right below the output, but that requires you to be there to press it.
You could try a burn-in program. [SiSoft] makes a program called Sandra which handles all sorts of benchmarking and similar functions as well as burn-in. It's kind of bloated but it does contain a module which will stress test your system quite thoroughly, and there is a freeware version (or was, should still be).
I personally run Java 1.4.1 under XP without issue. Microsoft shipped a pretty defective VM with WinXP (which as far as I can tell is gone by SP1), might want to double-check that you're using the Sun VM when you run Robocode. -- Kuuran
As I said above, I am trying all VMs I can find. Haven't tried the MS one though, it might be my best bet now strangely enough. -- PEZ
I've nailed it down finally! It's my CPU's doing Hyper Threading. This makes Java think there are more than one CPU and then thread locks can happen. Probably Robocode isn't prepared for multiple CPU's. I don't know why it only shows up with some bots though. Are you doing some threaded stuff inside Shadow ABC? Anyway, since I mainly use this machine for robocoding I disabled hyper threading in the BIOS and now Robocode runs smoother than ever! Yaaayyy! -- PEZ
Nope, no threads in my bots. It's a known fact that Robocode doesn't work well in multiple processor computers. Hyper-threading is, I believe, very much the same for the OS/aplications, so your best bet is to find a way to assign the Robocode task to a single "processor". I don't know if it is possible in XP, but I remember someone mentioning how to do it in WinNT?... -- ABC
You can do this from the Task Manager. Right click on the Java process and choose Set Afinity. Then select a "CPU" for the process to be run on. I found that I had two processors present when I know for a fact that I have only one in my machine (Wanted two but I knew Robocode had serious problems with dual proc machines). I am testing to see if this works. I will let you know of my results. Nice find PEZ. Hope this works. -- jim
Is there a way to make Windows remember the prefered afinity for an executable? -- PEZ
Found it!!! Use a tool in the Win2K resource kit called "imagecfg.exe". You find usage hints and a download link here: http://www.robpol86.com/misc_pgs/imagecfg.php I made a copy of "java.exe" (named it "rrjava.exe") and used imagecfg to set it's default affinity mask to only use one of the so called CPU:s. Then changed the roborumble.bat file to use rrjava. Then I made a "rjava.exe" to use the other so called CPU for "robocode.bat". Now I can go for serious Shadow hunting! -- PEZ
I had the exact same problem ! using a similar PC (3.00 GHz with Hyper Threading, XP, 1 GB ram, Ati Radeon 9800 Pro). some bots (including the one I'm currently working on) were freezing the game. Your solution seems to work flawlessly ! Thank you very much... DDA
So what are the specs on your new RoboRumble number crunching monster? --David Alves
Competetive as ever? What would you do if my machine had better specs than yours? =) Anyway, this page is quite old. The machine isn'¨t new any longer and WindowsXP Home seems to degenerate over time so now it doesn't run anything any fast at all. -- PEZ
"What would you do if my machine had better specs than yours?" Buy a new one. ;-) --David Alves
Good news! I think I have a fix for this! I'll post it with my UI improvements at OpenSourceRobocode/Contributions, and I'd appreciate anyone with a multi-proc or HyperThreading machine that has hit this before to re-enable it and test it out for me (and anyone who writes robots to try my new editor enhancements)! -- Kawigi
![[Home]](/images/RoboWiki.png)