Multi Player bugs and crashes - After the 24rd of February 2014

[Dancing Hoskuld]

Please report all multi-player bugs and crashes from the 24rd of February 2014 (release v34 = SVN Revision 7080)

When posting a an OOS, a bug or a crash please include

The version of C2C you are using;

The logs from all computers (especially the OoS log in the BtS exe folder and the random log in the normal Civ Logs folder).​

 

[Thunderbrd]

My wife and I are testing out the current MP status of this release version and are finding that while we were able to go a few hundred rounds without problems, we're starting to find new OOS errors popping in every four or five rounds now. Some basic evaluation suggests that these may be the result of Events. We're updating the SVN now and looking to verify this theory with a new game.

There's been GREAT work done on events this cycle but it makes me wonder if that's what's also making us OOS now.

We also do see the OOS errors being reported by the AND team regarding movement. Oddly, one observed behavior along those lines took place immediately when my wife moved the naval units only as far as they would go that round. On her comp she pinged where she'd moved them to and on mine they simply hadn't moved at all... so it may NOT just be an interruption of the route unless it was somehow interrupted as soon as she commanded them to move. Deleting the boats put us back in sync.

I've attached the Random and OOS logs for the two we took a deeper look at this evening and the second one is just... a huge WTH! The random logs are all over the place to the point that its next to impossible to see where it actually took place - but then I'm not entirely sure if it was derived from the round where we went out of sync. Very strangely it goes back to being fine then goes out again and goes back again and we generally set ourselves up so that we don't use any multi-threading. Perhaps some new multi-threading was introduced that doesn't rely on the global variable as to whether or not it's actually being utilized? I dunno... this one was very mysterious (took place as soon as the round began for us so showed nothing of an indication as to why or what may have caused it in-game.)

On the first one - the reason I'm suspicious of events shows clearly in the random log - it appears that one computer rolled for an event the other didn't. Not sure how that can happen but there it is plain as day. The same type of occurrence may also be the ultimate cause of the second random log but it's harder to be sure there.

I'm including python debug files - there's some very interesting discreps in there too...

 

[45°38'N-13°47'E]

We also do see the OOS errors being reported by the AND team regarding movement. Oddly, one observed behavior along those lines took place immediately when my wife moved the naval units only as far as they would go that round. On her comp she pinged where she'd moved them to and on mine they simply hadn't moved at all... so it may NOT just be an interruption of the route unless it was somehow interrupted as soon as she commanded them to move. Deleting the boats put us back in sync.

Regarding this specific OOS, we're experimenting with the fix proposed yesterday by AIAndy; during the week, when we reach Renaissance, I'll let you know how it goes.

 

[Thunderbrd]

Cool... thanks!

We had a frequent OOS problem yesterday that apparently is cleared up if both computers delete the cache files before loading again so it may've had something to do with a slight inconsistency in assets somewhere between us.

 

[Toffer90]

Now playing with "Revolutions", "Great Commander" & "Random Events" as a test.
We do have multi-threading enabled.

All these happened during AI turn.
Dropbox

 

[45°38'N-13°47'E]

Now playing with "Revolutions", "Great Commander" & "Random Events" as a test.
We do have multi-threading enabled.

All these happened during AI turn.
Dropbox

From my experience in AND, Revolutions, Events and Great Commanders aren't causing any trouble, I usually play with all of them turned on. But multithreading is still causing problems in multiplayer. At least in AND.

 

[Thunderbrd]

Great Commanders should at least be ok. All of the others are what I haven't debugged (though I'm not sure if there are OOS bugs in each - just still under suspicion.)

Since events differ in AND a lot I'm sure, there's clearly potential for some to lurk in the ones here but again, haven't proved either way yet. And yes, multi-threading has got known OOS errors and that may be unresolvable.

 

[khh]

Since events differ in AND a lot I'm sure, there's clearly potential for some to lurk in the ones here but again, haven't proved either way yet. And yes, multi-threading has got known OOS errors and that may be unresolvable.

From this I assume that multi-threading isn't currently being debugged. We'll turn it off for now, to make sure our logs are more helpful.

 

[Thunderbrd]

From this I assume that multi-threading isn't currently being debugged. We'll turn it off for now, to make sure our logs are more helpful.

Yeah it's not and won't be for a while. I'd have to learn a lot more about multi-threading as a whole to have a hope at being successful with that effort.

 

[Toffer90]

C2C MP is rock solid without multithreading, we played for 7-8 hours without a single OOS.
Perhaps a bug option should be added that turns off multithreading that is off by default but on by default when playing MP (if this is possible). This would make it easier for the non-forum-active C2C players to play MP.

Edit: Small MP Bug: when a player get their favourite religion without founding it himself all players get the pop-up about getting the religion.

 

[45°38'N-13°47'E]

C2C MP is rock solid without multithreading, we played for 7-8 hours without a single OOS.
Perhaps a bug option should be added that turns off multithreading that is off by default but on by default when playing MP (if this is possible). This would make it easier for the non-forum-active C2C players to play MP.

Edit: Small MP Bug: when a player get their favourite religion without founding it himself all players get the pop-up about getting the religion.

From my experience with AND, OOS get more frequent from Middle Age onwards. Have you already come so far?

 

[Thunderbrd]

Probably due to our games where we've hunted down the OOS errors not having gotten past that point before some major changes force the game to stop so we can eventually start a new one.

 

[Toffer90]

From my experience with AND, OOS get more frequent from Middle Age onwards. Have you already come so far?

Nah, we will need 7-8 hours more to get there. Probably won't happen till after summer, you guys will hear from us when we get there and have more OOS problems to report.

We are currently mid-ancient era playing on eons speed.

The ones we posted earlier were probably all caused by multithreading and are the only ones we've gotten so far.

 

[Toffer90]

I believe this has introduced an OOS problem that is repeatable and happens every time an AI declares war.

Spoiler :

SVN7445

Rewrite AI_bestMakePeaceTeam - AI now picks players to ask for peace intelligently and will ensure you can actually ask for peace from those players.
Remove strange code in AI_makePeaceTrade.

OOS report.

-
Edit: OOS 16 occured when I got a captive from attacking while on KHH's computer I did not get the captive.
OOS-16 is the only one that happended during human turn.
I believe the weirdness that units sometimes take a different path than what is calculated and showed graphically is the source of this OOS.
Captive spawned on different tile on the two computers (only difference).
-

 

[retired]

I believe this has introduced an OOS problem that is repeatable and happens every time an AI declares war.

Spoiler :

SVN7445

Rewrite AI_bestMakePeaceTeam - AI now picks players to ask for peace intelligently and will ensure you can actually ask for peace from those players.
Remove strange code in AI_makePeaceTrade.

OOS report.

From the changes i can't tell if that could cause an OOS sorry. The problem is i don't have a second computer to test for OSS problems and that disqualifies me from working on the dll at all.
I was working on some more advanced multithreading over the weekend but i realized i can't test how that behaves in terms of OOS problems and i trashed it all again.

 

[Thunderbrd]

From the changes i can't tell if that could cause an OOS sorry. The problem is i don't have a second computer to test for OSS problems and that disqualifies me from working on the dll at all.
I was working on some more advanced multithreading over the weekend but i realized i can't test how that behaves in terms of OOS problems and i trashed it all again.

I'm quite happy to look into the changes that were made and try to solve the OOS. As for multi-threading the golden rule is to rely on the global variable that controls that already. As long as we MPers can set it to 1 (no multi-threading) it should be safe.

I'll probably want to make that an adjustable variable in the BUG options at some point but I'm not sure if that would be code safe.

 

[Toffer90]

From the changes i can't tell if that could cause an OOS sorry. The problem is i don't have a second computer to test for OSS problems and that disqualifies me from working on the dll at all.
I was working on some more advanced multithreading over the weekend but i realized i can't test how that behaves in terms of OOS problems and i trashed it all again.

Don't let that stop you, coders can't test every aspect of their work. If you really introduced a bug, here's your chance to learn what you did wrong; that's far more important in the long run.

 

[retired]

I'm quite happy to look into the changes that were made and try to solve the OOS. As for multi-threading the golden rule is to rely on the global variable that controls that already. As long as we MPers can set it to 1 (no multi-threading) it should be safe.

I'll probably want to make that an adjustable variable in the BUG options at some point but I'm not sure if that would be code safe.

A bug option to set the number of threads is not a good idea at least not for what i was planning to use, it could only work if it is just a on-off option.
If you don't want the overhead that comes with any kind of multi-threading in a game with disabled multi-threading, it should be played using a dll without multi-threading code like CriticalSections.....

 

[Thunderbrd]

A bug option to set the number of threads is not a good idea at least not for what i was planning to use, it could only work if it is just a on-off option.
If you don't want the overhead that comes with any kind of multi-threading in a game with disabled multi-threading, it should be played using a dll without multi-threading code like CriticalSections.....

True... disabling multi-threading is simply all that's really necessary to consider. Would it be absolutely necessary to play it with a different dll or can we simply hinge all that setup and use of multi-threading on whether the 'simultaneous turns' option is on or not?

 

[retired]

True... disabling multi-threading is simply all that's really necessary to consider. Would it be absolutely necessary to play it with a different dll or can we simply hinge all that setup and use of multi-threading on whether the 'simultaneous turns' option is on or not?

It's not necessary to have a seperate dll without multi-threading if you can live with the performace loss caused by the multi-threading code e.g. CriticalSections. I don't think it's necessary at the moment.