This one seems to be related to convoys giving up replacement (https://forum.simutrans.com/index.php/topic,19962.0.html), although I did not get the issue isolated yet.
Hopefully the description will work, otherwise I'll need to dig deeper.
What happened?
I tried to force convoys, that gave up replacement, to reattempt entering a depot.
To do so, I first cleared the replacement and then setup replacement afresh.
In the last step the server crashed.
How to (hopefully) reproduce?
1. Run this nights backup (or the current save, if you are quick enough) on a server.
2. Join that server as a client.
3. Switch to Prominster Shipping & Coaches
4. Open one of the ER or WR lines, where there is a given up replacement. For example ER Lytbere - Beckborough, the first convoy of that line got such a replacement.
5. Open the replacement dialogue of that convoy
6. Check "Replace all", click "lear" and confirm with "Replace all"
7. Open the replacement dialogue of that convoy again.
8. Setup the Replacement again, check "Replace all" and confirm with "Full replace" again.
9. crash.
I am afraid that the backup system for saved games does not work as you suggest, so I will not be able to identify a specific backup for this state. For a reproduction case on a constantly changing online server game, I will need the reporter of the bug to save the game in the state where the bug can reliably be reproduced and upload that saved game with steps to reproduce the bug reliably from that specific saved game.
I was able to reproduce this reliably with the follow backtrace: Notably, 0x200000004 is an invalid memory address, and this occurs immediately after 'delete this' is called.
#0 0x000055555564dd9e in vector_tpl<quickstone_tpl<convoi_t> >::get_count (this=0x200000004) at dataobj/../network/../tpl/vector_tpl.h:318
No locals.
#1 0x0000555555a478f1 in replace_data_t::clear_all (this=0x5555817c56c0) at dataobj/replace_data.cc:269
i = 0
#2 0x000055555598ec77 in tool_change_convoi_t::init (this=0x5555b0e48520, player=0x55562d344f30) at simtool.cc:8601
sch = 0x5555b0e48520
le = {pos = {x = 0, y = 0, z = 0 '\000', static invalid = {x = -1, y = -1, z = -1 '\377', static invalid = <same as static member of an already seen type>}}, minimum_loading = 0, spacing_shift = 0,
waiting_time_shift = 0 '\000', reverse = 0 '\000', wait_for_time = false}
gr = 0x7fffffffad80
new_class = 180 '\264'
reset = 0
line = {static data = 0x5555565e2b00, static next = 1, static size = 1024, entry = 0}
compartment = 180 '\264'
good_type = 24
tool = 88 'X'
convoi_id = 2302
p = 0x5555ddb74d86 ""
cnv = {static data = 0x0, static next = 4097, static size = 8192, entry = 2302}
#3 0x00005555557d8ca6 in nwc_tool_t::do_command (this=0x55562e3a6690, welt=0x55555760ea40) at network/network_cmd_ingame.cc:1349
local = false
player = 0x55562d344f30
__PRETTY_FUNCTION__ = "virtual void nwc_tool_t::do_command(karte_t*)"
init_successful = true
#4 0x00005555559c4345 in karte_t::do_network_world_command (this=0x55555760ea40, nwc=0x55562e3a6690) at simworld.cc:10628
__PRETTY_FUNCTION__ = "void karte_t::do_network_world_command(network_world_command_t*)"
#5 0x00005555559c3cd2 in karte_t::process_network_commands (this=0x55555760ea40, ms_difference=0x7fffffffbbf0) at simworld.cc:10574
nwc = 0x55562e3a6690
ms = 312356
time_to_next_step = 13
nwc = 0x0
next_command_step = 5917
#6 0x00005555559c4a98 in karte_t::interactive (this=0x55555760ea40, quit_month=2147483647) at simworld.cc:10732
time = 312332
hashes_ok = {data = 0x0, size = 0, count = 0}
ms_difference = 0
#7 0x0000555555952155 in simu_main (argc=2, argv=0x7fffffffe588) at simmain.cc:1387
resolutions = {{640, 480}, {800, 600}, {1024, 768}, {1280, 1024}, {704, 560}}
disp_width = 704
disp_height = 560
fullscreen = 0
quit_month = 2147483647
path_sep = 0x555555a80a3f "/"
pak_diagonal_multiplier = 724
pak_tile_height = 8 '\b'
pak_height_conversion_factor = 2 '\002'
found_settings = true
found_simuconf = true
multiuser = true
simuconf = {file = 0x0}
path_to_simuconf = "config/simuconf.tab\000\000\000\000"
version = 0x555555a80b10 "Simutrans version 120.2.1 Extended Nightly development build 14.10 from Jun 3 2020 #662d59e\n"
cli_syslog_enabled = false
cli_syslog_tag = 0x0
It can reliably be reproduced at any time from yesterday evening on. Just crashed the game twice yesterday and once today, because I didn't notice this was the cause :/
I cannot upload such huge savegames to the forums.
I made a 'fix' that avoids the crash (but potentially creates more problems, potential memory leaks, broken behaviour, etc. I've tested it and not noticed these but it's possible). It at least shows that the problem area is the chain of 'delete' being passed around.
https://github.com/freddyhayward/simutrans-extended/tree/DONTMERGE-replace-crash
I am afraid that I have not been able to reproduce the crash described by Freahk following the instructions using my debug build, even though convoy 2302 was still in the state that he described.
I am concerned that Freddy's patch may cause memory leaks as a delete command is removed without replacement.
I have pushed a possible fix for this, but have not been able to test this since I cannot reproduce the crash. I should be grateful if people could re-test with the next nightly build.
Oh well, I strongly guess it's actually not server related but Linux related.
Just crashed the server when I attempted to delete one of those, to get rid of it btw.
Quote from: jamespetts on June 03, 2020, 04:54:35 PM
I have pushed a possible fix for this, but have not been able to test this since I cannot reproduce the crash. I should be grateful if people could re-test with the next nightly build.
Your fix appears to work from my testing.
Splendid, thank you for confirming.
I did not crash the server this time :)