FS#6169 - truck got a non-existing cargo

Attached to Project: OpenTTD
Opened by Sam (smhg) - Wednesday, 12 November 2014, 10:35 GMT
Type Bug
Category Vehicles
Status New
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version 1.4.4
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


Please have a look at the attached screenshot.
The information panel of the truck displays a cargo of 4,294,953,103 tonnes of wood.

The truck itself has orders to load and unload the same cargo at the same station. I am aware this is not a nice thing to do, but after a few rounds it suddenly got this huge cargo. While 3 other trucks doing the same orders behave normal.

I'm running version 1.4.4 on Ubuntu 14.10.

Please let me know if you need more information.
This task depends upon

Comment by Ingo von Borstel (planetmaker) - Thursday, 13 November 2014, 23:57 GMT
The game is from an unmodified 1.4.4 and will crash in trunk with
Message: Assertion failed at line 305 of /home/planetmaker/ottd/trunk/src/cargopacket.h: this->action_counts[MTA_KEEP] + this->action_counts[MTA_DELIVER] + this->action_counts[MTA_TRANSFER] + this->action_counts[MTA_LOAD] == this->count

[00] /home/planetmaker/ottd/trunk/bin/openttd(_ZNK12CrashLogUnix13LogStacktraceEPcPKc+0x37) [0x717047]
[01] /home/planetmaker/ottd/trunk/bin/openttd(_ZNK8CrashLog12FillCrashLogEPcPKc+0xeb) [0x6054cb]
[02] /home/planetmaker/ottd/trunk/bin/openttd(_ZNK8CrashLog12MakeCrashLogEv+0x48) [0x605708]
[03] /home/planetmaker/ottd/trunk/bin/openttd() [0x716f55]
[04] /lib64/ [0x7ff964f6b8f0]
[05] /lib64/ [0x7ff964f6b877]
[06] /lib64/ [0x7ff964f6cf68]
[07] /home/planetmaker/ottd/trunk/bin/openttd() [0x704c88]
[08] /home/planetmaker/ottd/trunk/bin/openttd() [0x4e6fcc]
[09] /home/planetmaker/ottd/trunk/bin/openttd(_ZN16VehicleCargoList5StageEbt10SmallStackIttLt65535ELt8ELt65533EEhPK10GoodsEntryP12CargoPayment+0xc46) [0x5ed1c6]
[10] /home/planetmaker/ottd/trunk/bin/openttd(_Z13PrepareUnloadP7Vehicle+0x1fc) [0x6129dc]
[11] /home/planetmaker/ottd/trunk/bin/openttd(_ZN7Vehicle12BeginLoadingEv+0x258) [0x839228]
[12] /home/planetmaker/ottd/trunk/bin/openttd(_Z31IndividualRoadVehicleControllerP11RoadVehiclePKS_+0x1590) [0x761270]
[13] /home/planetmaker/ottd/trunk/bin/openttd(_ZN11RoadVehicle4TickEv+0x116) [0x7618a6]
[14] /home/planetmaker/ottd/trunk/bin/openttd(_Z16CallVehicleTicksv+0xbb) [0x837fab]
[15] /home/planetmaker/ottd/trunk/bin/openttd(_Z13StateGameLoopv+0x23f) [0x70711f]
[16] /home/planetmaker/ottd/trunk/bin/openttd(_Z8GameLoopv+0xf8) [0x707f28]
[17] /home/planetmaker/ottd/trunk/bin/openttd(_ZN15VideoDriver_SDL8MainLoopEv+0x204) [0x844474]
[18] /home/planetmaker/ottd/trunk/bin/openttd(_Z12openttd_mainiPPc+0x13d3) [0x706423]
[19] /lib64/ [0x7ff964f57d65]
[20] /home/planetmaker/ottd/trunk/bin/openttd() [0x55b8ad]
Comment by Remko Bijker (Rubidium) - Friday, 02 January 2015, 13:38 GMT
The issue planetmaker gets is because it got corrupted, mostly because stable releases do not perform all those sanity checks.

Besides that this issue bothers me a lot. I can't find a way where things do go wrong.
* the number is near-ish the value of 0 - 1 (actual about -14000), if only numbers >= 0 would be used (i.e. it is about 2 to the power of 32).
* in the savegame it is only 51343, but essentially it the same number (but with an underflow to 2 to the power of 16). But that's probably because only 16 bits are stored in the savegame.
* such an underflow implies that it must have happened with unloading, or a negative (or really huge) amount was loaded.
* the maximum amount to unload is the minimum of amount of cargo in the vehicle and the "load amount" (the amount to unload during gradual loading), which means the step may be at most 5 but no negative numbers are allowed since it is unsigned.
* the actual unloading works with only positive numbers and before doing anything it limits the amount to at most the amount of cargo and the load amount, i.e. the minimum of the amount of loaded cargo and the load amount.
* during loading something similar happens, only positive amounts and all bounded by load amount.

As such I'm not seeing how the values got so negative unless there has been a memory corruption somewhere, or a bug in some totally different location of the code that for some reason overwrites the data at this location.
Comment by andythenorth (andythenorth) - Wednesday, 23 August 2017, 07:01 GMT
Possible tar pit reproducing this? I've got a test game running, but the chances of rolling a dice and triggering this seem very low.