News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Today's Bridgewater-Brunel Windows client crashes at game load

Started by Matthew, December 06, 2020, 11:29:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Matthew

The Bridgewater-Brunel Windows client, downloaded today (2020-12-06, #1b3a304), reproducibly crashes at the very start of game load. In network games it crashes after transferring the save, at the very start of the loading process. With an offline Bridgewater-Brunel map it crashes at the start of game load.

Here is the backtrace:


These are the last lines in simu.log:
QuoteMessage: network_command_t::rdwr:    read packet_id=17, client_id=0
Warning: nwc_routesearch_t::rdwr:    rdwr limits=(1024, 9093, 3535, 20149248, 345536) apply_limits=1
Warning: network_check_activity():    received cmd id=17 nwc_routesearch_t from socket[6476]
Warning: nwc_routesearch_t::do_command:    apply limits=(1024, 9093, 3535, 20149248, 345536)
Message: karte_t::load():    Prepare for loading
Message: karte_t::load():    Time is now: 256881
World destroyed.

I could not reproduce the crash with a self-compiled #1b3a304 (using MSYS2, GDI for Windows and available here).

Given the backtrace, I speculate that this problem was caused by the B-B Ubuntu upgrade yesterday: perhaps a dependency related to pthreads/winthreads has moved or changed version.

Another possible line of enquiry is this is somehow related to the path explorer speed adjustment code, since the client log ended with the "apply limits" message. But it is harder to see how that has changed since yesterday.

The server is also crashing sporadically, but I don't know whether this is related or not.

I guess it would be interesting to know whether others have the same problems.

Actually, having written this, I guess a corrupted download could be the problem too. But seems less likely to me since the client did actually connect to the server (confirmed from server log). Also, the Nightly Updater hash function might detect a corrupted download and it hasn't.

EDIT: Another thought. James, if it turns out that you are going to have set up dependencies again, then you might want to have another try at upgrading to Ubuntu 20.04. That puts off the day when you have to repeat the exercise from 2023 to 2025.....

jamespetts

Thank you for the report; I confirm that I am able to reproduce the symptoms described, and unable to reproduce the crash on my locally compiled builds. I should note that I did upgrade to 20.04.1 when I performed the upgrade, as 18.04 still did not have a zstd version recent enough to compile. The problem is not a corrupt saved game as I can load the same saved games with local builds, and the crash occurs whenever the game is started, whether or not a saved game is loaded.

The crash appears to occur at different points in the load/save cycle, suggesting that the crash is occurring other than in the main thread. This is consistent with what you have discovered in the backtrace that path_explorer_threaded is the issue.

I am afraid that this is likely to be fantastically difficult to track down and may well take many months of intensive work to deal with.

As a preliminary inquiry, may I ask whether anyone has tested the latest Linux client to see whether that is working correctly?

Vladki

I am unable to run extended nightlies, due to:

./simutrans-extended: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./simutrans-extended)
./simutrans-extended: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./simutrans-extended)

(My glibc is 2.24 - debian 9).

And stephenson-siemens is down for the same reason, as it has glibc 2.27 (ubuntu 18.04).

freddyhayward

Quote from: jamespetts on December 08, 2020, 08:30:28 PMAs a preliminary inquiry, may I ask whether anyone has tested the latest Linux client to see whether that is working correctly?
Yes, the linux client is working correctly.

Vladki

I have compiled myself, locally it works well, but I can't connect tu bridgewater due to pakset mismatch - is the server running the latest pakset version?

freddyhayward

Quote from: Vladki on December 08, 2020, 09:49:01 PMI have compiled myself, locally it works well, but I can't connect tu bridgewater due to pakset mismatch - is the server running the latest pakset version?
the master branch recently merged a change that bridgewater has not yet updated to. however it should still work fine if you force connect.

jamespetts

Thank you for your feedback. I suspect that the problem might be that the include files for pthreads may now be for a later version than the cross-compile library files, as the latter are entirely manually compiled and have not been recompiled since the upgrade. I will investigate this theory further.

jamespetts

Investigating the issue in connexion with setting up libraries to build the zstd version, I have been able to build that version without the crash occurring. I suspect that the problem might be that the SDL version in the includes did not match the SDL version in the libraries. I have now changed this in the build setup for cross-compiling; I should be grateful for any feedback as to whether this is fixed in to-morrow's nightly build.

Matthew

Quote from: jamespetts on December 09, 2020, 01:56:24 AM
Investigating the issue in connexion with setting up libraries to build the zstd version, I have been able to build that version without the crash occurring. I suspect that the problem might be that the SDL version in the includes did not match the SDL version in the libraries. I have now changed this in the build setup for cross-compiling; I should be grateful for any feedback as to whether this is fixed in to-morrow's nightly build.

I have tested today's Windows client from Bridgewater-Brunel (2020-12-09, #cecd155). It runs and connects to the Bridgewater-Brunel online game without any difficult. Thank you for the swift fix!  :thumbsup:

jamespetts

Excellent, thank you for confirming. I am relieved that this was able to be resolved simply.