Freeze with -Ddebug=true

18 views
Skip to first unread message

Matthew Gerber

unread,
Mar 9, 2021, 8:58:12 AM3/9/21
to robocode-developers
Hello - 

I am using -Ddebug=true, and the game freezes when a round ends. I'm attaching a screenshot of the game in its frozen state. No error messages are emitted, and the game will sit in this state indefinitely until I kill it. Has this been observed before?

Thanks!

Matt 

Screen Shot 2021-03-09 at 8.54.05 AM.png

Pavel Šavara

unread,
Mar 9, 2021, 10:07:45 AM3/9/21
to robocode-...@googlegroups.com
Hi Matt,

could you please try to reproduce it on the released version of Robocode ? It would be good to know if this is caused by recent changes. Also, what version of JRE are you running it on ?

Thanks
Pavel

--

---
You received this message because you are subscribed to the Google Groups "robocode-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robocode-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/robocode-developers/f7870781-7a03-4e6d-83fe-f02da246aa58n%40googlegroups.com.

Matthew Gerber

unread,
Mar 10, 2021, 8:51:59 AM3/10/21
to robocode-...@googlegroups.com
Hi Pavel - 

I poked around and noticed a couple things:
  • I believe there is a simple bug here:  10 seconds in milliseconds is 10 * 1000 and not 10 * 60 * 1000 (which is 10 minutes). So, when I saw the game "freeze", it was actually just waiting 10 minutes to iterate turns.
  • The freeze (or slow turn iteration) only happens at the end of a round when my robot wins.
  • Interestingly, I was not able to get the battle to freeze using the sample robots. There is something specific about my "networked / RL" robot that causes the freeze. I think this has something to do with the sleeping status of my robot thread. My robot keeps a TCP socket open, and it blocks while waiting for the RL server to send it a message. As a result, I suspect that my robot thread never sleeps, and this code waits for the robot to sleep.
  • By setting the debug wait time to 500ms, 250ms, etc., the game will iterate at these speeds at the end of each round when my robot wins.
So there's definitely a bug to fix per above, but I haven't yet sorted out why my use of TCP sockets causes the slow turn iteration at the end of a round. Suggestions welcome!

Matt

You received this message because you are subscribed to a topic in the Google Groups "robocode-developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/robocode-developers/w3OyofHEij8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to robocode-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/robocode-developers/CABB%2B0733Wc40-N3OKSbghmUpNs5962UTTiB9wBseg70JoP%3D5uw%40mail.gmail.com.

Pavel Šavara

unread,
Mar 10, 2021, 12:56:08 PM3/10/21
to robocode-...@googlegroups.com
On Wed, Mar 10, 2021 at 2:52 PM Matthew Gerber <gerber....@gmail.com> wrote:
Hi Pavel - 

I poked around and noticed a couple things:
  • I believe there is a simple bug here:  10 seconds in milliseconds is 10 * 1000 and not 10 * 60 * 1000 (which is 10 minutes). So, when I saw the game "freeze", it was actually just waiting 10 minutes to iterate turns.
I think that's just a bad comment and that 10 minutes is OK.
 
  • The freeze (or slow turn iteration) only happens at the end of a round when my robot wins.
  • Interestingly, I was not able to get the battle to freeze using the sample robots. There is something specific about my "networked / RL" robot that causes the freeze. I think this has something to do with the sleeping status of my robot thread. My robot keeps a TCP socket open, and it blocks while waiting for the RL server to send it a message. As a result, I suspect that my robot thread never sleeps, and this code waits for the robot to sleep.
  • By setting the debug wait time to 500ms, 250ms, etc., the game will iterate at these speeds at the end of each round when my robot wins.
So there's definitely a bug to fix per above, but I haven't yet sorted out why my use of TCP sockets causes the slow turn iteration at the end of a round. Suggestions welcome!

The robot is expected to return control to the engine and sleep at the end of every turn. So you can't wait on the socket after the end of turn. Perhaps you will need to also create a separate thread for that ?


 

Matthew Gerber

unread,
Mar 10, 2021, 11:15:36 PM3/10/21
to robocode-...@googlegroups.com
On Wed, Mar 10, 2021 at 12:56 PM Pavel Šavara <pavel....@gmail.com> wrote:


On Wed, Mar 10, 2021 at 2:52 PM Matthew Gerber <gerber....@gmail.com> wrote:
  • The freeze (or slow turn iteration) only happens at the end of a round when my robot wins.
  • Interestingly, I was not able to get the battle to freeze using the sample robots. There is something specific about my "networked / RL" robot that causes the freeze. I think this has something to do with the sleeping status of my robot thread. My robot keeps a TCP socket open, and it blocks while waiting for the RL server to send it a message. As a result, I suspect that my robot thread never sleeps, and this code waits for the robot to sleep.
  • By setting the debug wait time to 500ms, 250ms, etc., the game will iterate at these speeds at the end of each round when my robot wins.
So there's definitely a bug to fix per above, but I haven't yet sorted out why my use of TCP sockets causes the slow turn iteration at the end of a round. Suggestions welcome!

The robot is expected to return control to the engine and sleep at the end of every turn. So you can't wait on the socket after the end of turn. Perhaps you will need to also create a separate thread for that ?

I eventually figured out that the robot thread was failing to sleep at the end of each round because it was waiting for the RL server to close the socket. I've changed the server, and now everything works well with -Ddebug=true 

Thanks!

Matt
Reply all
Reply to author
Forward
0 new messages