[http://sourceforge.net/p/ufoai/bugs/3395 Item 3395] imported from sourceforge.net tracker on 2013-01-28 20:08:16

After a few turns, in the battlescape in single player, at the end of a turn the alien enemy moves and then I loose the ability to influence the action. I can scan around the screen and select my soldiers, however as far as I can tell, they don't refresh their time units and I can't reposition them.

However, if I press return several times or press the UI button to move to the next turn, I can see in the console that my units continue to take damage and units that were outo of sight of the enemy may be killed by the aliens.

Eventually, I get out of the situation by pressing ESC and quitting the game.

I have run into this problem on two maps, most recently on the Eaglesnest map.

I am attaching the ufoconsole log. The error seems to happen at line 634, "2012/10/12 18:14:37 Team 7 ended round".
===== Comments Ported from Sourceforge =====

====== eldermann (2012-10-12 17:12:21.173000) ======

More info: this happens reliably whenever I play this save.

I run Linux Mint XFCE on a Dell Core 2 Due, 2.4 MHz, 2 GB RAM, NVIDIA Quadro NVS 160M, graphics driver "295.40-0ubuntu1.1".
====== darkrainx (2012-10-12 17:59:17.416000) ======

can you attach your save? I'd like to take a look.
====== eldermann (2012-10-12 18:09:46.964000) ======

Here's the game I'm playing. The transport's on it's way to the encounter. It usually takes several turns before the game glitches.
====== darkrainx (2012-10-12 20:39:17.861000) ======

I managed to reproduce this once, but further tries have been unsuccessful so far, anyway looking at events.log it seems as if events stopped being processed client-side, server side the game continued, and I eventually won (reaction fire) but the client remained 'frozen' in the battlescape.
====== darkrainx (2012-10-15 02:53:35.173000) ======

After trying unsuccessfully to reproduce this again, it happened when I wasn't expecting it (ie when I was just playing)... and I found that I was actually able to shoot and kill my own soldiers in that state, of course it was only noticeable in the console output.
I enabled DEBUG_EVENTSYS output as soon as I realized I had hit the bug again, note the absence of output from e_parse.cpp

====== darkrainx (2012-10-15 02:56:11.771000) ======

Extract from the events log for that session, note that the last event registered matches the time the bugged turn started (in the ufoconsole.log)
====== freakyd (2012-10-17 00:26:43.350000) ======

my events.log ended the same with EV_ACTOR_STATS as the last line when the UI thing started. Also a bt on what it's doing shows
0 0x0000003b044ea643 in select () from /lib64/libc.so.6
1 0x00000000004a44c3 in NET_Wait (timeout=12) at src/common/net.cpp:430
2 0x0000000000498b93 in Qcommon_Frame () at src/common/common.cpp:1431
3 0x00000000005165c6 in main (argc=1, argv=0x7fffffffe0c8)
at src/ports/linux/linux_main.cpp:55
and only the timeout value ever changes. in my ufoconsole.log it showed the ExecuteString: 'updateactorvalues 7 "soldiers/malelight/head01" "111" "111" "32" "32" "146" "146" "0" "Zuberi Zhang
HP: 111/111 TU: 32
Plasma Rifle"'
ExecuteString: 'deselect_crouch'
ExecuteString: 'crouch_checkbox_clear'
ExecuteString: 'reserve_shot_clear'
ExecuteString: 'deselect_reaction'
ExecuteString: 'deselect_reloadright'
ExecuteString: 'disable_reloadleft'
ExecuteString: 'deselect_headgear'
ExecuteString: 'deselect_primaryright'
ExecuteString: 'disable_primaryleft'
ExecuteString: 'deselect_crouch'
ExecuteString: 'crouch_checkbox_clear'
ExecuteString: 'reserve_shot_clear'
ExecuteString: 'deselect_reaction'
ExecuteString: 'deselect_reloadright'
ExecuteString: 'disable_reloadleft'
ExecuteString: 'deselect_headgear'
ExecuteString: 'deselect_primaryright'
ExecuteString: 'disable_primaryleft'
and that's it.
====== aduke1 (2012-10-28 23:56:29.780000) ======

- **assigned_to**: DarkRain

====== darkrainx (2012-12-12 22:04:06.866000) ======

Ok I found a bug in dbuffer::getAt that caused it to read beyond the buffer length under certain circumstances, this in turn caused the net stream to be filled with garbage, and could cause NET_ReadMsg to perpetually fail waiting for a message with an unholy length...
Should be fixed by 873800a7c217b8d0b426ebf9ff69a2adfc95befa, please report otherwise.
====== darkrainx (2012-12-13 19:45:08.362000) ======

I will close this now, please report if this happens again.
====== darkrainx (2012-12-13 19:49:08.039000) ======

- **status**: open --> closed