r24148 - Actor movement out of sync - server crashed

[Kaz]

Hey Duke! Thanks for the debugging tip. I will try it some time later. For the moment, I'm more than happy to keep sending in detailed bug reports and pound on the spanish translation.

Cheers!

[Duke]

I can compile again So I did some testing. I can confirm a bunch of pathfinding probs with the tower on the dam.map, including being forced to crouch and walking through walls.
Many of them are caused by the map not being 'designed to the grid'.
But I didn't get the crash.

@Kaz:
Just a thought: Do you happen to use a multi-core cpu ? (I'm on an ooold single-core)

[ralthor]

I've been playing with this bug trying to reproduce it.  I have been using the Dam map and getting the error: 

********************
ERROR: LET_PathMove: Actor movement is out of sync: 132:138:1 should be 135:137:1 (step 1 of 1) (team 1)


I never saw the out of TUs error (although it seems to be related).  I couldn't make it consistent from point a->b, but this is how I was able to reproduce it easily:

If you go to the second floor and crouch and move through the wall so you are standing outside the building.  Then run off a bunch of your TUs so that you can click inside the second floor at a place that is to far for you to actually move to, but also a place on the second floor that you can move to standing (i.e. near the stairs from the ground floor to 1st floor).  What should happen is your character will stand up, almost all your TUs will be used up, and nothing else will happen.

On your next turn any movement will crash the game.

I hope this helps if it is not clear or you want grid positions I can grab those, but I wanted to type this up real quick before I went on to my other business tonight.


----

edit, oh yea I am using r24374 and I thought it was consistent clicking to a 'standing' spot to far away, but it isn't 100% consistent, trying to figure out why.  Fresh compile of everything (first time trying 2.3 and it is amazing, great job so far).

[ralthor]

Ok couldn't let it go at then, developed an even better algorithm, I have done this a dozen times in almost this exact same way and it has always crashed on me at some point going through it, it seems to depend on where the civilians/aliens are as to when it will crash.

Using r24374, compiled with debug option (not that my attempts at debugging it have gone anywhere), Windows xp 32 bit, AMD Phenom II X3, Radeon 4870 1GB

Here what I do:

Start game, Goto single player, skirmish, switch map to dam, start.  Do debug_map 3

1)  Grab closest player to tower and run him as clost to the stairs as possible.  End turn
2)  Send the player to 136, 138, 1 (sometimes it will crash right here, seems to happen if you go through a civilian).
3)  Move him outside the building, usually I go to 133, 135, 1 or within 1 space of that area.
4)  If there is enough TU crouch and end turn, otherwise just end turn
5)  If you haven't crouched yet, crouch, then try to go to 135, 136, 1 (on the stairs).
6)  Sometimes it crashes right here, if it doesn't crash it leaves the player standing in the same spot with no TUs, if it didn't crash end turn
7)  Try and goto 135, 136, 1 again 
  ... I have never gotten this far without it crashing.

[Kaz]

I can compile again So I did some testing. I can confirm a bunch of pathfinding probs with the tower on the dam.map, including being forced to crouch and walking through walls.
Many of them are caused by the map not being 'designed to the grid'.
But I didn't get the crash.

@Kaz:
Just a thought: Do you happen to use a multi-core cpu ? (I'm on an ooold single-core)

I will try the issue again and check if the crash is consistent. As for your question: yes, I have a Core 2 Duo. If I get consistent results, do you think fiddling with the processor affinity to bind the ufo.exe process to a single core would make it behave exactly as a single core system, or does ufoai change its behavior depending on the number of cores/processors?

Cheers!

[Duke]

@ralthor:
Thank you very much for your work:) Following your description, I got the 'crash' too. Aaand I saw a ton of pathfinding bugs there.

@Kaz:
Honestly, I don't know. I only know that multithreading and multi-cores are different 'layers' of multitasking and thus may cause different problems. As I got the crash on a single core, we can investigate that topic later

As it's just a 'crash to mainmenu', the debugging is not as easy as it would be for CTD.
Fixing the pathfinding issues might hide the crash. So I'd like to fix the crash *first*.
Could any of you apply Mattn's fix above and see if the crashing persists (before I find the time to do it) ?

[Kaz]

Ok. Here is my consistent way to obtain the crash, step by step.

1. Goto (137,135,1).
2. Crouch.
3. End turn.
4. Move to (135,138,2): Fails: Square turns yellow if using debug_map.
5. Move to (135,136,1): Crash!

I've tried it several times, and this crashes the game every single time.

@Duke.
I'll look into Mattn's patch and let you know what I find.

Cheers!

[Kaz]

Tried Mattn's patch. Still crashes at the same spot.

Cheers!