Topic: Bridgewater-Brunel no. 1 - Great Britain sized map (no. 2)

[fam622]

I also have that same problem.

[AP]

Update: I have managed to connect once after a further quarter hour of trying, but the game is paused, and has been that way for 15 25 minutes or so now. So I can't do anything... but it is definitely still connected to the online game, I have the little icon in the RH corner. I presume it can't desynch if the game is static...

[DrSuperGood]

The server appears to be offline atm.

[jamespetts]

Apologies for the difficulties: the server seems to have crashed. I have restarted it running in an instance of a debugger; I should be grateful if people could attempt to join so that I can catch the error causing the crash in the debugger and set about fixing it. Thank you in advance.

[Ves]

It was me who made it stop in this infinite loop I think.
I was buying a bunch of boats I believe, but I can’t remember exactly what I did to make it stale. I believe I made them go out on the map already, but I don’t recall.

[jamespetts]

Having run this with a debugger, I am getting a strange error indicating memory corruption, so I am running it again with Valgrind to see what the origin of the problem is. I should again be grateful if people could attempt to connect to try to trigger the error.

Note: Because I am running this in Valgrind, I am afraid that the loading process will be much slower than normal. I am joining at present, so it may be several minutes before anyone else can join.

For reference, the backtrace was:

Code: [Select]


(gdb) backtrace
#0  __GI___libc_free (mem=0x800030300) at malloc.c:2951
#1  0x00000000004628a9 in strasse_t::~strasse_t() ()
#2  0x000000000046bb26 in objlist_t::~objlist_t() ()
#3  0x00000000004517e0 in boden_t::~boden_t() ()
#4  0x00000000006dcf17 in planquadrat_t::~planquadrat_t() ()
#5  0x0000000000718cc9 in karte_t::destroy() ()
#6  0x000000000072ce15 in karte_t::load(loadsave_t*) ()
#7  0x000000000073067e in karte_t::load(char const*) ()
#8  0x00000000005a385e in nwc_sync_t::do_command(karte_t*) ()
#9  0x0000000000725ae2 in karte_t::do_network_world_command(network_world_command_t*) ()
#10 0x000000000072618b in karte_t::process_network_commands(int*) ()
#11 0x000000000073d06f in karte_t::interactive(unsigned int) ()
#12 0x00000000006cd6c2 in simu_main(int, char**) ()
#13 0x00000000006e1807 in sysmain(int, char**) ()
#14 0x00007ffff6b45830 in __libc_start_main (main=0x40efb0 <main>, argc=21, argv=0x7fffffffe458, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffe448) at ../csu/libc-start.c:291
#15 0x000000000040f019 in _start ()

Edit: I have had to restart Valgrind because there were so many errors (mostly in code from Standard, particularly the image node reader) that Valgrind refused to display any further errors before the occasion of the crash arose, so I had to disable the error number limit, which required restarting Valgrind. I anticipate that it will be 15-20 minutes before it will be possible for anyone to join.

[jamespetts]

From the testing undertaken last night, the problem appears to be some sort of heap corruption, although I am having problems reproducing this reliably enough to test properly: see here for a more detailed discussion of the heap corruption issue.

I have pushed a speculative fix, consisting of reverting an earlier optimisation that affects the same type of object as that in which the heap corruption appears be occurring. It is speculative because I have not been able to reproduce the crash locally reliably enough for a properly controlled test. This is now being deployed to the server, so I should be grateful if anyone could try to connect to the server with the version of the executable downloaded from the server from about 30 minutes after the posting of this message to test whether the problem recurs or not.

Thank you in advance to any testers, and apologies for the difficulties.

Edit: Server now confirmed as restarted with the updated version.

[AP]

Apologies to players getting annoyed by error messages from my companies. I started lots of Stage Coaches without realising the roads cannot yet support them, and I'm now unable to get back into the game to fix. Will do so as soon as I can. Have reported the pakset issue.

[Ves]

I didnt see any notifications about that, so no worries 

However, I have seen this pattern twice now:
- Being online, someone starts to connect, the game prepares etcetc.
- Then the long eternal wait for the pausing to become complete.
- After a very long wait, the game appears to save again, initiating another join process
- But when the view returns to the game and one is just about to start the eternal wait, it disconnects

I was online together with AP, and I believe AP was online with me at the same time when it happened the first time. Second time I believe I was alone.

[asaphxiix]

Am I still the only one who is having intermittent 'not enough bytes transferred' when trying to join? It's a very strange bug indeed.

[AP]

I didnt see any notifications about that, so no worries 

However, I have seen this pattern twice now:
- Being online, someone starts to connect, the game prepares etcetc.
- Then the long eternal wait for the pausing to become complete.
- After a very long wait, the game appears to save again, initiating another join process
- But when the view returns to the game and one is just about to start the eternal wait, it disconnects

I was online together with AP, and I believe AP was online with me at the same time when it happened the first time. Second time I believe I was alone.

Yes I've seen this behaviour, including tonight.

[DrSuperGood]

Please post the sort of disconnect.

[Ves]

I asked before, how do you see what kind of disconnect it is? you talked about a logfile, where is this file?

[DrSuperGood]

It should be printed on the server log. One can also see it with the clients by starting in logging mode and running the client in a terminal/console window where it gets printed to.

My offer still stands for anyone who wants to share my company.

[AP]

Hi James. I managed to break a river tile, please can I ask you to fix it?  The co-ordinates are in a signpost as you enter the game. I managed to upgrade wide river with narrow canal and now have a permanent constriction on the river traffic that shouldn't be there. THanks.

[asaphxiix]

incidentally, I would very much like to understand how canals can be built...

[AP]

incidentally, I would very much like to understand how canals can be built...

There is a YouTube tutorial video on "inland navigations".

One notable 'quirk' is that there are hard coded altitude restrictions on each type of canal. Rivers of equivalent width do not have the same restriction.

Edit: link added.

[Ves]

Server appears to be down?

[AP]

I agree, it is down.

[jamespetts]

My apologies: I have been very busy in the last few days: I will look into this when I have a chance.

[jamespetts]

The server seems to have become stuck in an infinite loop. I do not currently know the cause of the problem, but I have now restarted it. My apologies for the difficulties.

[asaphxiix]

Hello,

May I ask that the Board of Trade or Bay Transports remove or change to bridge the road on <1350,2562>?

Thank you

[Ves]

The map appears to be offline?

[jamespetts]

Confirmed offline, investigating.

Edit: Server back up. The problem appeared to have been a corrupted saved game, probably caused by the server crashing while the game was saving. This sort of problem is very difficult to track down, especially as I have not been able to get the logs to work recently. Any insight into the possible causes of crashes of this sort would be much appreciated, even information about what happened when a server crash occurred would be worthwhile.

[DrSuperGood]

Most of last nights progress was lost. If not even the day before... And it saved like a dozen times during then. Like 15 lines I set up were removed.

Here (link may be removed in the future) is a save from the server yesterday, which is significantly more progressed than the current one.

[asaphxiix]

Indeed much progress was lost. However I have already put much effort after this.

[AP]

Has there been a recent pakset change on the Bridgewater server?
I'm using the latest nightly exe and it's showing a mismatch (pakset name "Pak128.Britain-Ex-0.9.3" is in red).

Yet that's exactly the pakset I'm using (it's the same as Canterbury server uses).

Running "Find Mismatch" compares the pakset and gives the following result:

Code: [Select]

Pak(s) different: Stage coach (rigid)
Obviously we can keep multiple pakset versions for playing different games, but I imagine it will get mightily confusing if they are numbered exactly the same yet differ.

[jamespetts]

My apologies for the lost progress - I had hoped that a restore from server13353-restore.sve would have been the most recent save, as the timestamp on that save was more recent than the backups: it had a timestamp of 0605h, whereas the rotated backups had a timestamp of 0602h yesterday morning. I am not entirely sure what server13353-restore.sve is for, but I shall note not to use it in preference to my normal rotated backups again.

Given that progress has been made since the reversion, I will leave this for now, but I will note that server13353-restore.sve is not a useful restore point unless there are no other alternatives.

As to the pakset, this has indeed been updated: the rigid stage coach now has a slightly higher top speed, so you will need to update to the latest pakset to avoid losing syhcnronisation with the server.

[AP]

As to the pakset, this has indeed been updated: the rigid stage coach now has a slightly higher top speed, so you will need to update to the latest pakset to avoid losing syhcnronisation with the server.

If the pakset is changed, why is it still reporting 0.9.3?  Should it not now be 0.9.4 or 0.9.31 or something?  I'm just pondering how I can have two different versions of 0.9.3 at the same time. Should not versions be uniquely numbered? Otherwise how can the game offer me the choice between them when it starts?

[jamespetts]

If the pakset is changed, why is it still reporting 0.9.3?  Should it not now be 0.9.4 or 0.9.31 or something?  I'm just pondering how I can have two different versions of 0.9.3 at the same time. Should not versions be uniquely numbered? Otherwise how can the game offer me the choice between them when it starts?

Versioning the pakset is not a straightforward endeavour. The executable is versioned in three separate ways: (1) by the Standard version number from which it is derived (currently 120.2.1); (2) by the Extended version number (currently 13.0); and (3) by the revision number (currently #704ca0f). The first of these changes whenever the Standard version number changes in the underlying code merged into Simutrans-Extended; the second changes whenever there is a significant new feature; and the third changes whenever there is any change to the code at all committed to Github.

The pakset, by contrast, only has the one version number, 0.9.3 currently. Importantly, this is a manually set version number, not an automated revision. This is treated in the same way as the second type of version number for the executable: in other words, it is changed whenever there is a significant feature change. This means that minor alterations (e.g. bug fixes) will not trigger a version number change.

It is done this way because it is impractical, in the context of a nightly release system, manually to increment the version number with every minor adjustment made. Instead, players will know whether or not the pakset needs updating by seeing whether there is a pakset mismatch when they try to connect to the server, and, if there is, downloading the new pakset.

I hope that this clarifies matters.

[AP]

I believe the Bridgewater server has just crashed, whilst I was starting ships from a shipyard. This was after a respectable amount of construction of lines and prior use of shipyards without incident.

[jamespetts]

May I ask you to let me know which ships, which shipyard and which lines that they served?

Edit: I think that I have now found and fixed this error. The fix should be available in to-morrow's nightly build. I should be interested to see whether this error recurs after that.

[DrSuperGood]

Given that progress has been made since the reversion, I will leave this for now, but I will note that server13353-restore.sve is not a useful restore point unless there are no other alternatives.

Seeing how most of the progress that was lost by the reversion was mine this makes me quite angry... multiples hours of work thrown away.

Sigh ill get back to work catching up.

[jamespetts]

Seeing how most of the progress that was lost by the reversion was mine this makes me quite angry... multiples hours of work thrown away.

Sigh ill get back to work catching up.

I am very sorry - it is very difficult to know what to do in such a situation when I first discover the issue after further work has been done.

[DrSuperGood]

Due to a bug with the current nightly, do not play on the server.

Cities currently produce no passengers at all. Since all the companies depend heavilly on passengers for their income this means that all companies are making huge losses at the moment. Playing is pointless until this is fixed and will harm all companies by burning away their money and potentially bankrupting them.