View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004210Spring engineGeneralpublic2013-12-15 05:432013-12-16 00:29
ReporterGoogle_Frog Assigned ToKloot  
PrioritynormalSeveritymajorReproducibilitysometimes
Status closedResolutionsuspended 
Product Version95.0.1+git 
Summary0004210: 95.0.1-196 Desync
DescriptionThis game desynced. The desync seems to be correlated with a nuke impact which happens at about 50:25, 2300, 5400.

A replay did not save for psimyn or awsom1324567 and the rest of the players ran away after the game.
Additional InformationZK r12262
TagsNo tags attached.
Attached Files
20131215_141822_LowTideV3_95.0.1-195-g9228a54 develop.sdf (Attachment missing)
Checked infolog.txt for Errors

Activities

Kloot

2013-12-15 14:51

developer   ~0012392

Since ZK stills desyncs regularly with 91 and was the only game to do so before the release of 94 (which means you need to check *all* of its Lua code), this report can't be considered valid.

Also, a giant 50-minute replay has pretty much zero chance of being watched.

Google_Frog

2013-12-15 15:45

reporter   ~0012393

How is any desync not an engine bug? Do you have a complete list of things not to do in lua? If they cannot be done then why are they not blocked (or if this is impossible they should at least be in the wiki). Every issue jK could think of proved to not be present. Furthermore the desync seemed to occur before the version in which we thought it was introduced so it probably went unreported for a long time.

How do you know that 91.0 was not broken as well? BA barely uses any engine features and the other games don't have the playerbase to ever detect this sort of bug. But even that is irrelevant, the fact remains that a game running with your engine desyncs so it is basically an engine bug. There are no helpful debug messages and you cannot argue that desyncs are intended behaviour.

Sure, I can check lua, but for what? I've also heard rumors of sync debug builds. If those were set up we could run them on the test engine hosts.

Kloot

2013-12-15 16:51

developer   ~0012394

Last edited: 2013-12-15 17:00

 "How is any desync not an engine bug?"

Don't be dense...


"Do you have a complete list of things not to do in lua?"

No but it should be obvious if you understand the concept of sync. After 5+ years of being active on the CA/ZK front I would expect that you do.

Note that I do not trust every game developer to have this understanding, certainly not all ZK devs seem to.


"How do you know that 91.0 was not broken as well?"

Every release is broken in the sense that it contains bugs. That's why we released 94 and 95.

Not every release is broken in the sense that it generates desyncs.

The long runup to 94 and the large number of non-ZK games played with 91 means we can be certain with high probability that there were no undiscovered desync sources in the 91 codebase.

Similar reasoning applies to the long period between 94 and 95.


"BA barely uses any engine features and the other games don't have the playerbase to ever detect this sort of bug."

Misconception and false assumption.

A desync is no different from ordinary bugs regarding its chances of being found and we get plenty of those from the smaller games.


"But even that is irrelevant, the fact remains that a game running with your engine desyncs so it is basically an engine bug."

Our engine allows you the flexibility of breaking it, yes, just like some programming knowledge allows you the flexibility of breaking your system. That still makes it your responsibility when it breaks unless you can prove you aren't abusing said flexibility.


"I've also heard rumors of sync debug builds"

http://springrts.com/wiki/Debugging_sync_errors

Google_Frog

2013-12-15 17:22

reporter   ~0012395

Last edited: 2013-12-15 17:24

 ""How is any desync not an engine bug?"

Don't be dense..."

No, really. The engine has allowed the synced luarules states to differ between machines. The engine controls the information passes to luarules and should ensure that the interior is deterministic. How is a failure to do so not an engine bug? What can occur inside luarules which causes divergence?

""Do you have a complete list of things not to do in lua?"

No but it should be obvious if you understand the concept of sync. After 5+ years of being active on the CA/ZK front I would expect that you do.

Note that I do not trust every game developer to have this understanding, certainly not all ZK devs seem to."

It is not obvious at all. As far as I am aware we have 3 distinct lua states, synced luarules, unsynced luarules and luaui. Synced luarules executes deterministically and every piece of information that can affect it passes through the engine. With this conception of the system I cannot see anything that I should not do in lua. There is no documentation of non-deterministic behaviour within luarules and mixing between the states in an unsafe way should be prevented.

I don't trust that the problem is not in the engine. Earlier attempts at fixing this desync revealed that synced and unsynced luarules used references to the same pairs function. This could be used to pass information from unsynced to synced which would of course cause games to desync. When developing lua it would be reasonable to assume that synced and unsynced luarules do not use references to the same function so modifying functions in unsynced luarules should be safe. This bug was fixed by jK a few months ago.


The link on the wiki page is dead. http://buildbot.springrts.com/builders/full-windows
The most recent sync debug build is 94.1.1-1017-gd82987f. If you have a non-dead link could you see if a sync debug build can be built for the latest develop version?

Kloot

2013-12-15 17:43

developer   ~0012396

"The engine has allowed the synced luarules states to differ between machines."

No, you have.


"The engine controls the information passes to luarules and should ensure that the interior is deterministic. How is a failure to do so not an engine bug? What can occur inside luarules which causes divergence?"

The engine controls the information *PASSED TO* lua(rules).

It *DOES NOT* control the information *INSIDE* lua(rules).


"Synced luarules executes deterministically and every piece of information that can affect it passes through the engine. With this conception of the system I cannot see anything that I should not do in lua."

Here's a little quiz to challenge your conception then. What is the output of

  t = {}
  for i = 1, 3 do
    t[{}] = t
  end
  for k,v in pairs(t) do
    print(k,v)
  end

when executed multiple times?


"There is no documentation of non-deterministic behaviour within luarules"

Yes, there is. Search the wiki.


"The link on the wiki page is dead."

use http://buildbot.springrts.com/builders/full-windows-test

Rafal99

2013-12-15 21:37

reporter   ~0012397

GoogleFrog: "Every issue jK could think of proved to not be present."

This included iterating over table indexed with tables. No such case was found in ZK code.
We even have a custom pairs function that would spam errors if any code tried to iterate over table-indexes and no errors were found despite hundreds of games in ZK stable.

Kloot

2013-12-16 00:12

developer   ~0012403

Last edited: 2013-12-16 00:28

 Then (given the frequency at which ZK desyncs 91) you should have no problem reproducing it with 95+ in a *short* test game. At a minimum we expect you to upload a demo of that instead of some hour-long chaosfest that diverges only at the end if you want this to be investigated because desync bugs take an *enormous* amount of effort to track down and involve running the same replay dozens of times which is just not feasible with the one attached here.

Issue History

Date Modified Username Field Change
2013-12-15 05:43 Google_Frog New Issue
2013-12-15 05:43 Google_Frog File Added: 20131215_141822_LowTideV3_95.0.1-195-g9228a54 develop.sdf
2013-12-15 14:51 Kloot Note Added: 0012392
2013-12-15 14:51 Kloot Status new => closed
2013-12-15 14:51 Kloot Assigned To => Kloot
2013-12-15 14:51 Kloot Resolution open => won't fix
2013-12-15 15:45 Google_Frog Note Added: 0012393
2013-12-15 15:45 Google_Frog Status closed => feedback
2013-12-15 15:45 Google_Frog Resolution won't fix => reopened
2013-12-15 16:51 Kloot Note Added: 0012394
2013-12-15 16:56 Kloot Note Edited: 0012394
2013-12-15 17:00 Kloot Note Edited: 0012394
2013-12-15 17:03 Kloot Status feedback => closed
2013-12-15 17:03 Kloot Assigned To Kloot =>
2013-12-15 17:03 Kloot Resolution reopened => suspended
2013-12-15 17:22 Google_Frog Note Added: 0012395
2013-12-15 17:22 Google_Frog Status closed => feedback
2013-12-15 17:22 Google_Frog Resolution suspended => reopened
2013-12-15 17:24 Google_Frog Note Edited: 0012395
2013-12-15 17:43 Kloot Note Added: 0012396
2013-12-15 21:37 Rafal99 Note Added: 0012397
2013-12-16 00:12 Kloot Note Added: 0012403
2013-12-16 00:27 Kloot Note Edited: 0012403
2013-12-16 00:28 Kloot Note Edited: 0012403
2013-12-16 00:29 Kloot Status feedback => closed
2013-12-16 00:29 Kloot Assigned To => Kloot
2013-12-16 00:29 Kloot Resolution reopened => suspended