The International Simutrans Forum

 

Author Topic: [BUG]: Transfer times near 2^32  (Read 345 times)

0 Members and 1 Guest are viewing this topic.

Online VOLVO

  • *
  • Posts: 103
[BUG]: Transfer times near 2^32
« on: May 20, 2020, 07:51:14 AM »
Many passengers now seems to be stuck at "Transfers" on the stations, and does not get inside the station or on any ship, I think this is a bug?

Offline freddyhayward

  • *
  • Posts: 172
  • Languages: EN
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #1 on: May 20, 2020, 08:34:00 AM »
This is happening on all saves since the most recent build. I suspect it's because of the large merged pull request that fixed many compiler warnings.

Offline freddyhayward

  • *
  • Posts: 172
  • Languages: EN
[BUG]: Transfer times near 2^32
« Reply #2 on: May 20, 2020, 08:51:37 AM »
Transfer times for all stops are all at 1193046:28:10 which totals 4294967290 seconds which is just under the maximum size for a uint32. Therefore this likely has something to do with the recent changes to signed/unsigned integer conversions.

Offline freddyhayward

  • *
  • Posts: 172
  • Languages: EN
Re: [BUG]: Transfer times near 2^32
« Reply #3 on: May 20, 2020, 09:23:43 AM »
I have now submitted a pull request that fixes the problem.

Offline ceeac

  • *
  • Posts: 123
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #4 on: May 20, 2020, 11:17:54 AM »
Reverting commit 65192df78 seems to fix the issue. The bug seems to be a side effect of removing using namespace std from float32e8_t.h and the compiler silently changing std::max/std::min for max/min. The results of these differ for large unsigned integers because std::max/std::min make an unsigned comparison and max/min make a signed comparison (see simtypes.h).

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19684
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #5 on: May 20, 2020, 11:23:22 AM »
Thank you for the report - I have now reverted the commit to which ceeac refers. I should be grateful if people could confirm whether this is fixed with to-morrow's nightly build.

Offline Freahk

  • *
  • Posts: 960
  • Languages: DE, EN
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #6 on: May 20, 2020, 12:02:54 PM »
I've just built the latest master and can confirm transfer times work again, that means newly generated passengers will arrive at the stop again.

However, passengers that already are in transfer will remain in transfer for a long time, so an emergency mechanism might be required when loading such games, otherwise there will be passengers in transfer for roughly the next 15 milleniums...

Due to that very huge number, it should be fine to simply detect any transfer times greater than 2^31 seconds and reset these to a reasonable low value.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19684
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #7 on: May 20, 2020, 12:20:34 PM »
I've just built the latest master and can confirm transfer times work again, that means newly generated passengers will arrive at the stop again. However, passengers that already are in transfer will remain in transfer for a long time, so an emergency mechanism might be required when loading such games, otherwise there will be passengers in transfer for roughly the next 15 milleniums... Due to that very huge number, it should be fine to simply detect any transfer times greater than 2^31 seconds and reset these to a reasonable low value.
Thank you for that suggestion. I have added the following code, which I hope will suffice:
Code: [Select]
if (tc.ready_time > current_time + UINT32_MAX_VALUE)
            {
                // HACK: Fix after-effects of bug from 20 May 2020 causing extremely high transnfer times.
                // This can be removed shortly afterwards.
                transferring_cargoes[i].remove(tc);
                tc.ready_time = current_time + 10000;
                transferring_cargoes[i].append(tc);
            }

Offline freddyhayward

  • *
  • Posts: 172
  • Languages: EN

Offline Freahk

  • *
  • Posts: 960
  • Languages: DE, EN
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #9 on: May 20, 2020, 02:29:17 PM »
I have reviewed that change. I don't think the logic is correct.
Current time is in tick unit, which is real-world miliseconds.
Mentioned 2^32 transfer times were related to ingame seconds, not to ticks.
2^32 ingame seconds is something bewteeen 2^39 and 2^40 ticks at pak128.britain-ex' default settings.
That means wour fix won't work.

Anyways, I have prepared a different approach to hotfix this, when loading the save.
It will properly take care of seconds to ticks conversation and ignores any transfer times where more than 2^31 seconds are remaining, simply setting their arrival time to "now".

I have pushed these changes to my github. It can be found here:
https://github.com/jamespetts/simutrans-extended/pull/174

The PR is based on a version before your hotfix and does not undo it. You'll need to do this in addition.
« Last Edit: May 20, 2020, 05:36:49 PM by Freahk »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19684
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: BUG - Pak128.Britian on the Bridgewater-Brunel No.3 Server
« Reply #10 on: May 20, 2020, 10:16:21 PM »
Thank you - now incorporated.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19684
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: [BUG]: Transfer times near 2^32
« Reply #11 on: May 20, 2020, 11:10:41 PM »
I have merged the two topics as these refer to the same issue. Thanks to Freddy for the fix to this and apologies that this was duplicated.