Author Topic: Desync issue (devel-new-2) with Linux Server/Windows client (Read 34039 times)

Vladki · « **Reply #105 on:** January 10, 2017, 12:37:25 AM »

Yes I'm running Linux. I think the "normal desync" happens when you tamper with something - typically schedule, or vehicles in depot. But if you just watch the game it should be ok. And most importantly you can reconnect again.

Ves · « **Reply #106 on:** January 10, 2017, 01:28:32 AM »

Normal desync was in contrast to the crashes mentioned earlier. They occurred without doing anything. Yes I run windows.

Felix · « **Reply #107 on:** January 10, 2017, 10:20:32 PM »

On server.exp.simutrans.com:13354 the game runs without the initial disconnect. I also tried to build some stuff, which also works.

I am running the game in Linux (64-bit). The pakset is actually newer than the one on the server (9a8d1a8e61c296a1d65303643f1f268f0ad24e40). I forced the connection via "load" dialog.

jamespetts · « **Reply #108 on:** January 10, 2017, 11:31:04 PM »

Testing again, I do desync within <10 seconds of connecting both on the Bridgewater-Brunel server and on server.exp.simutrans.com:13354. I notice that server.exp.simutrans.com:13354 reports having the routemaster-rescaled object whereas the Bridgewater-Brunel server does not (and nor does my client).

jamespetts · « **Reply #109 on:** January 11, 2017, 06:17:22 PM »

Testing with my Linux client and compiling from the latest commit on devel-new-2 for the code and half-heights for the pakset, I desync shortly after connecting both to the Bridgewater-Brunel server and to server.exp.simutrans.com:13354 (although not as quickly as with my Windows machine). I have connected to the default port of server.exp.simutrans.com and have not desynced yet (after circa 2-3 minutes). Edit: Still connected about 20 minutes later.

However, I am not sure that the Bridgewater-Brunel server or server.exp.simutrans.com are running the latest versions.

Felix · « **Reply #110 on:** January 12, 2017, 10:16:16 PM »

On the Bridgewater-Brunel server and with a build of the latest sources, my client crashes right after the connect with a segmentation fault.

jamespetts · « **Reply #111 on:** January 12, 2017, 10:59:31 PM »

Thank you for testing. Are you able to run GDB to find where the fault occurs? I should note that I have been integrating a lot of updates from Standard this evening, so the server will not be up to date with the latest code on Github; desyncs are known to cause crashes in some cases for reasons that remain elusive (the crash occurs in code that is unmodified from Standard).

Felix · « **Reply #112 on:** January 13, 2017, 08:43:10 PM »

I hope the following is already helpful for you. If you need something else, please, let me know.

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0x000000000040e57e in player_t::get_player_nr (this=0x0) at bauer/../player/simplay.h:302
302             sint8 get_player_nr() const {return player_nr; }
(gdb) bt
#0  0x000000000040e57e in player_t::get_player_nr (this=0x0) at bauer/../player/simplay.h:302
#1  0x000000000076a7ad in tool_add_message_t::init (this=0x14fb3cd0, player=0x0) at simtool.cc:9102
#2  0x00000000005ea5af in nwc_tool_t::do_command (this=0x153dc310, welt=0x35bd830)
    at network/network_cmd_ingame.cc:1339
#3  0x00000000007975c5 in karte_t::do_network_world_command (this=0x35bd830, nwc=0x153dc310) at simworld.cc:9714
#4  0x0000000000796fe3 in karte_t::process_network_commands (this=0x35bd830, ms_difference=0x7fffffffb158)
    at simworld.cc:9659
#5  0x0000000000797c3a in karte_t::interactive (this=0x35bd830, quit_month=2147483647) at simworld.cc:9820
#6  0x000000000072ffaa in simu_main (argc=2, argv=0x7fffffffda68) at simmain.cc:1370
#7  0x0000000000742cd0 in sysmain (argc=2, argv=0x7fffffffda68) at simsys.cc:805
#8  0x00000000007ffb6f in main (argc=2, argv=0x7fffffffda68) at simsys_s2.cc:800

jamespetts · « **Reply #113 on:** January 13, 2017, 09:00:16 PM »

Thank you for that. It is difficult to tell exactly what is going on there and therefore the ultimate cause, but I have just pushed a fix that might help to deal with the immediate cause. Are you able to re-test? I should be grateful.

Felix · « **Reply #114 on:** January 13, 2017, 09:14:17 PM »

Will do so immediately.

jamespetts · « **Reply #115 on:** January 13, 2017, 09:18:35 PM »

Thank you - that is very kind.

Felix · « **Reply #116 on:** January 13, 2017, 09:26:26 PM »

Now, the game is running very slow, when I try to connect and I get "no response from server" when trying to force the connect via load dialog.

jamespetts · « **Reply #117 on:** January 13, 2017, 09:29:23 PM »

That is very odd indeed, and extremely difficult to understand. Is the game running slowly for you even in single player mode? What map are you running?

Felix · « **Reply #118 on:** January 13, 2017, 09:32:02 PM »

Sorry, should have been more clear. The game starts to respond slowly once I click on the "play online" button or try to connect to a server via load dialog. I am currently on the devel-new-2 branch. I got quite a number of patched files, when I pulled. So it might be related to something else that was pushed. Of course, my build configuration might be also less then optimal.

I also cannot see any server in the server browser, even if I select to also display mismatched. I can ping the server.

jamespetts · « **Reply #119 on:** January 13, 2017, 09:35:19 PM »

Taking a long time to respond when actually selecting an individual server in the list is usually caused by that server being slow to respond. Is this what you are experiencing?

Felix · « **Reply #120 on:** January 13, 2017, 09:37:38 PM »

No, the game gets slow and consumes an unusual amount of CPU time once I open the server dialog. Before selecting anything within the dialog window.

But I think it is unlikely to be caused by the change you commited. Trying to bisect the other commits, now.

jamespetts · « **Reply #121 on:** January 13, 2017, 09:42:27 PM »

That is very odd indeed. It performs normally before attempting to connect to the server?

Edit: Even more oddly, I cannot reproduce this in Windows.

Felix · « **Reply #122 on:** January 13, 2017, 09:45:09 PM »

Yes, it performs normal, if not trying to connect to a server.

By the way, are you using IRC or something?

ecb9712b19b66298062464702410c69702119a26 does not have the issue. Still no response from the server.

jamespetts · « **Reply #123 on:** January 13, 2017, 09:50:39 PM »

I am currently in the process of doing some work on the Bridgewater-Brunel server to try to get it up to the latest version, enable automatic version numbering, and make sure that the server is always running the latest nightly build. Because of my poor multi-tasking skills, IRC may not work well at present in any event. However, the as a result of that, the Bridgewater-Brunel server is not currently running.

Edit: Incidentally, are you able to identify the latest version that does not have this problem?

Felix · « **Reply #124 on:** January 13, 2017, 09:52:00 PM »

Ok, I will continue to try to investigate the issue.

jamespetts · « **Reply #125 on:** January 13, 2017, 09:53:21 PM »

That is very kind - thank you.

Felix · « **Reply #126 on:** January 13, 2017, 09:54:08 PM »

The issue with the slow speed after opening the network dialog was introduced with commit 959405a1da3cc2b569a508e371ed10b4f9f55720.

Might be a setup issue on my side, but reintroducing "local_hints.ai_socktype = SOCK_STREAM;" in line 237 of network.cc fixes the slowness problem for me.

I can connect to the bridgewater-brunel copy on server.exp.simutrans.com:13354 without crashing, now, but I still get the desync after some seconds.

jamespetts · « **Reply #127 on:** January 13, 2017, 10:50:14 PM »

I have just been looking into this. That was the commit in which I merged in some of Dr. Supergood's network changes; however, they seem to have been merged into an already outdated network code-base. I have now managed to bring it fully up-to-date with the latest code in Standard. Do you think that you could re-test with this new code?

Felix · « **Reply #128 on:** January 13, 2017, 10:57:31 PM »

jamespetts · « **Reply #129 on:** January 13, 2017, 10:59:00 PM »

Thank you.

Felix · « **Reply #130 on:** January 13, 2017, 11:05:55 PM »

This change also fixes the slowness issue. The crash issue seems also to be resolved. Still get the desync, though.

jamespetts · « **Reply #131 on:** January 13, 2017, 11:07:06 PM »

Excellent - thank you for re-testing. That is some progress at least.

Felix · « **Reply #132 on:** January 13, 2017, 11:12:25 PM »

Definitely! Let me know, when you need something tested.

jamespetts · « **Reply #133 on:** January 13, 2017, 11:36:14 PM »

Thank you again.

I have now restarted the Bridgewater-Brunel server with the latest version. Do you think that you could re-test for the desync? Thank you again.

Felix · « **Reply #134 on:** January 13, 2017, 11:39:28 PM »

I seem to have a different revision than the server. If I force the connection via load, I still get the desync :-(

(just trying to get some more debug information)

jamespetts · « **Reply #135 on:** January 13, 2017, 11:46:48 PM »

I think that the different revision is caused by an issue discussed here.

Are you able to run Simutrans-Experimental as a server on your own computer (use the "-server" command line flag), load the same saved game as is on the Bridgewater-Brunel server, and then connect to it with another instance of Simutrans-Experimental running on your own computer using the "net:127.0.0.1" command in the load dialogue to see whether that stays in sync?

Felix · « **Reply #136 on:** January 13, 2017, 11:51:30 PM »

With a local server I could also run the map before.

jamespetts · « **Reply #137 on:** January 13, 2017, 11:53:02 PM »

Can you test whether this is still the case with the latest build?

Felix · « **Reply #138 on:** January 13, 2017, 11:59:45 PM »

Do you happen to have a fresh dump of the savegame? Mine might be outdated.

jamespetts · « **Reply #139 on:** January 14, 2017, 12:01:15 AM »

The best thing to get the exact same thing as is running on the server is to connect to the server, wait for it to desync, then save the game.