agrif wrote:

I'm running the server we were able to reproduce this on, and would be happy to try anything to help resolve this bug. I also have two details to add.

First, my client was not disconnected when the vactrains were running, though everybody else's was; as far as I could tell this had nothing to do with what I was doing or what company I was in.

Second, we tested the following versions of dedicated server (in order) and all of them failed: 1.1.5 via Gentoo Portage, 1.2.0-beta3 from source with CFLAGS="-O2 -pipe -march=native", r23845 from source with "-O2 -pipe -march=native", and r23845 with no custom CFLAGS. Everything after the first was configured with "--enable-dedicated --without-liblzo2".

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10785

michi_cc wrote:

Could you run the server (and maybe also the clients where possible) with "./openttd -d desync=2" (+ any other arguments you usually pass) and report back if you get any unusual console output?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10786

agrif wrote:

Nothing interesting, and only two new messages: "'brownan' reported an error and is closing its connection (desync error)" on the server, and "Sync error detected!" on the client.

We also attempted to follow the instructions here: http://wiki.openttd.org/OpenTTDDevBlackBook/Network/Desync_debugging , but the client timed out every time it tried to connect, with "Your computer took too long to join".

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10788

michi_cc wrote:

So no cache mismatch it seems. That makes debugging it a lot harder :(

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10789

Rubidium wrote:

Actually, -ddesync doesn't log to the console but to save/autosave/commands-out.log.

So please make a savegame, then run openttd -D -ddesync=3 -g. When people have desynced you should upload the commands-out.log and the initial savegame to here. Please keep the dmp_cmds_*.sav savegames as we might need those at a later stage.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10791

brownan wrote:

We can most likely try -ddesync=3 later today (this evening, EST). I see that there is indeed a commands-out.log on the client and server, as well as two dmp_cmds_*.sav files on each, presumably from our runs with -d desync=2 last night. The server also has a random-out.log (which is 12MB).

Would you like me to upload the commands-out.log files from last night?

Also, would you like us to clear out the commands-out.log files before we try -ddesync=3?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10792

Rubidium wrote:

commands-out.log gets overwritten when starting OpenTTD again, but yet the previous commands-out.log would be interesting together with the savegame you loaded to start the game.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10793

Rubidium wrote:

It would be nice if you would be able to reproduce the desync with the latest nightly. That would prevent us from chasing some possible desyncs that have been fixed recently. Still running it with -ddesync=3.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10797

brownan wrote:

Sorry we didn't get around to doing that yesterday. Looks like our schedules didn't sync up. When we get a chance we'll do a -ddesync=3 test with the latest nightly and report back.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10798

brownan wrote:

We ran the latest nightly: r23850, with -ddesync=3. I'm attaching the client commands-out.log. agrif should be attaching the server save file and server commands-out.log shortly.

Attachments

• commands-out-client.log (0.49 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10801

agrif wrote:

We've just run the bug with -ddesync=3; here's the log and save file. We're using the r23850 nightly (both server and client) for this.

Attachments

• commands-out.log (1.91 KiB)
• vactrain-bug.sav (314.77 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10802

Rubidium wrote:

Could you both upload the dmp_cmds_3b45c1f9_000c2c80.sav file from save/autosave? So one from the client and one from the server.

Can you also tell me what kind of hardware the server uses? Especially the type of CPU, together with the operating system you're using and whether it's a 32 or 64 bits server. Finally I'd like to know whether you compiled OpenTTD yourself, or whether you downloaded it from our site. If it's the latter, which one did you download exactly?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10804

agrif wrote:

Here's the server's copy.

I'm running the server on a Xen VM (Linode 512, specifically). The CPU reports itself as 4 cores, "Intel(R) Xeon(R) CPU L5520 @ 2.27GHz", and I'm running 32-bit Gentoo with a linux kernel that reports itself as "2.6.39.1-linode34".

I couldn't find any no-graphics builds on the website, so I've been compiling it myself. This bug was tested on a r23850 nightly source tarball configured with "--enable-dedicated --without-liblzo2".

Attachments

• dmp_cmds_3b45c1f9_000c2c80.sav (314.61 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10805

brownan wrote:

Attached is the client dmp_cmds_3b45c1f9_000c2c80.sav. If it's relevant, I've been downloading the binaries from the site to run the client. This one right here: http://binaries.openttd.org/nightlies/trunk/r23850/openttd-trunk-r23850-linux-generic-amd64.tar.xz

Attachments

• dmp_cmds_3b45c1f9_000c2c80.sav (314.60 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007#comment10806

Rubidium closed the ticket.

Reason for closing: Fixed

In r23855

This comment was imported from FlySpray: https://bugs.openttd.org/task/5007