News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

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 2 Guests 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(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.