News:

SimuTranslator
Make Simutrans speak your language.

Pull request: Narrower debug sums focused on private cars

Started by freddyhayward, September 22, 2021, 09:09:28 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

freddyhayward

This pull request is a revision of my previous one (see: https://forum.simutrans.com/index.php/topic,21145.0.html).

As stated in that post:
Quote from: freddyhayward on September 18, 2021, 10:40:29 AMMy hypothesis is that there is a discrepancy in the random behaviour of cars or pedestrians. If this is correct, then we would observe differences in these new sums which would help to further isolate the problem. If not, another approach will have to be found.

Desync reports since then have indeed shown a discrepancy in the number of random rolls within a specific branch of the private car logic. Since these reports do not feature any random seed discrepancies, I believe that the overall number of rolls is compensated for in another branch of the private car logic.

This pull request (see: https://github.com/jamespetts/simutrans-extended/pull/447) replaces the pedestrian debug sum with that other branch. My revised hypothesis is that private cars occasionally find routes on the server that they do not find on the client. If this is correct, the server will record higher values for sum [8] and lower values for sum [9] compared to the client. Hopefully, this will get us closer to the root of the problem.

jamespetts

Thank you for your ongoing work on this - it is much appreciated. Pull request now incorporated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

As the private car approaches the goal, it destroys itself and is reborn as two pedestrians. So, if the behavior of private car is different, the spawning of pedestrian will also be different.

PJMack

I am not sure if this helps or not, but while debugging something else, valgrind found an uninitialized value in the road vehicle.  I pasted the results below, (they are from the pak128.britian default savegame), however the compilation was highly optimized, so the file names, function names and line numbers are to be taken with a grain of salt.

==276446== Thread 1:
==276446== Conditional jump or move depends on uninitialised value(s)
==276446==    at 0x2804A5: road_vehicle_t::enter_tile(grund_t*) (road_vehicle.cc:1105)
==276446==    by 0x275C19: vehicle_t::hop(grund_t*) (vehicle.cc:1685)
==276446==    by 0x27EA4A: road_vehicle_t::hop(grund_t*) (road_vehicle.cc:1141)
==276446==    by 0x279D0D: vehicle_base_t::do_drive(unsigned int) (vehicle.cc:332)
==276446==    by 0x279EDC: road_vehicle_t::do_drive(unsigned int) (road_vehicle.cc:1042)
==276446==    by 0x37D909: UnknownInlinedFun (simconvoi.cc:1333)
==276446==    by 0x37D909: convoi_t::sync_step(unsigned int) (simconvoi.cc:1226)
==276446==    by 0x2C6EFD: karte_t::sync_list_t::sync_step(unsigned int) (simworld.cc:4864)
==276446==    by 0x2C7088: karte_t::sync_step(unsigned int, bool, bool) (simworld.cc:4938)
==276446==    by 0x1F71C8: UnknownInlinedFun (simintr.cc:111)
==276446==    by 0x1F71C8: interrupt_check(char const*) [clone .constprop.0] (simintr.cc:91)
==276446==    by 0x2C2EA4: karte_t::step() (simworld.cc:5700)
==276446==    by 0x32D8C5: UnknownInlinedFun (simmain.cc:265)
==276446==    by 0x32D8C5: modal_dialogue(gui_frame_t*, long, karte_t*, bool (*)()) (simmain.cc:200)
==276446==    by 0x2A5BCB: UnknownInlinedFun (simmain.cc:1610)
==276446==    by 0x2A5BCB: sysmain(int, char**) (simsys.cc:1097)
==276446==  Uninitialised value was created by a heap allocation
==276446==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==276446==    by 0x2B50F2: karte_t::load(loadsave_t*) (simworld.cc:9782)
==276446==    by 0x2BA0E5: karte_t::load(char const*) (simworld.cc:9135)
==276446==    by 0x2A4468: UnknownInlinedFun (simmain.cc:1493)
==276446==    by 0x2A4468: sysmain(int, char**) (simsys.cc:1097)
==276446==    by 0x48900B2: (below main) (libc-start.c:308)
==276446==
==276446== Conditional jump or move depends on uninitialised value(s)
==276446==    at 0x2804A5: road_vehicle_t::enter_tile(grund_t*) (road_vehicle.cc:1105)
==276446==    by 0x37EEC3: convoi_t::move_to(unsigned short) (simconvoi.cc:478)
==276446==    by 0x38224A: UnknownInlinedFun (simconvoi.cc:3486)
==276446==    by 0x38224A: convoi_t::step() (simconvoi.cc:2224)
==276446==    by 0x2C301A: karte_t::step() (simworld.cc:5807)
==276446==    by 0x32D8C5: UnknownInlinedFun (simmain.cc:265)
==276446==    by 0x32D8C5: modal_dialogue(gui_frame_t*, long, karte_t*, bool (*)()) (simmain.cc:200)
==276446==    by 0x2A5BCB: UnknownInlinedFun (simmain.cc:1610)
==276446==    by 0x2A5BCB: sysmain(int, char**) (simsys.cc:1097)
==276446==    by 0x48900B2: (below main) (libc-start.c:308)
==276446==  Uninitialised value was created by a heap allocation
==276446==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==276446==    by 0x2B50F2: karte_t::load(loadsave_t*) (simworld.cc:9782)
==276446==    by 0x2BA0E5: karte_t::load(char const*) (simworld.cc:9135)
==276446==    by 0x2A4468: UnknownInlinedFun (simmain.cc:1493)
==276446==    by 0x2A4468: sysmain(int, char**) (simsys.cc:1097)
==276446==    by 0x48900B2: (below main) (libc-start.c:308)

freddyhayward

Quote from: PJMack on October 06, 2021, 10:59:01 PM
I am not sure if this helps or not, but while debugging something else, valgrind found an uninitialized value in the road vehicle.  I pasted the results below, (they are from the pak128.britian default savegame), however the compilation was highly optimized, so the file names, function names and line numbers are to be taken with a grain of salt.
I have since narrowed down the problem to the presence or absence of private car routes stored on road tiles. Having worked in this area of the code, can you speculate as to what might cause this to fall out of sync between server and client?

PJMack

I looked at the diff for my last commit (95e014d41561e2b063a597bd4c96134760296856) for this area of code, and do not notice anything obvious, but then again I am admittedly less than familiar with exactly how client-server synchronization works.  My only speculation at the moment is that it may be something to do with the routes being calculated in a separate thread, asynchronous to the rest of the game mechanics.