Topic: Online checklist mismatches (was: Clients keep disconnecting)

[TurfIt]

Thanks for pursuing. It's nice to get beyond the 'it's just me' phase...
waitlock issue? I've noticed trains getting stuck in the 'schedule changing' mode quite often. Seems if their associated line schedule is changed while they're in a station loading they get stuck for an extended time.

[Dwachs]

It appears that r7731 (and then r7742) indeed fixed this desync by accident.

There was a train with route_index == route.get_count(), which called the block_reserver in can_enter_tile due to next_block+1<route_index. However, block_reserver immediately returned false, which was ignored, then cnv->set_next_stop_index was called, but next_signal and next_crossing were not assigned in block_reserver -> undefined value propagating.

valgrind would have found this, but I could not get to run it on my machine, the savegame was just too heavy.

[TurfIt]

That's great news then.
Is your desync-debugging code something in a shareable state?

Isn't a train with route_index==route.get_count() calling the block_reserver an error in the first place?

[Dwachs]

I will upload a patch in the evening.

Isn't a train with route_index==route.get_count() calling the block_reserver an error in the first place?

Don't know. That would need further investigation.

[Dwachs]

Here is a patch for debugging desyncs. Both client and server have to be compiled with the patch enabled (-DDEBUG_DESYNC, there are also new files network/network_debug.*).

Upon desync, client and server exchange data (like calls to simrand etc). The first difference found will be reported in a new window inside the client and written to desync.log.

With

Code: [Select]

network_debug_add(format, ....)
new debug messages can be added (both on client and server) with a printf-like syntax. These message strings make up the data that is automatically compared. Usually several runs of adding debug messages & running until desync are necessary. I was lucky that the desync did not went away while adding the debug code.

[prissi]

I think this woulb be a very useful addition. On might rather call it NETWORK_DBG() to be in place with the "normal" DEBUG_DBG(). Then it can be always there but only does something on real network debug build.

[TurfIt]

That's a very nice debugging tool. Hopefully never needed again!

[Isaac.Eiland-Hall]

Hopefully never needed again!

I know you already qualified it with "hopefully", but that still sounds like famous last words.