Pre-release testing: Simutrans-Experimental 10.4

[jamespetts]

The next version of Simutrans-Experimental is nearly ready for release, but, since there are a number of new features, I should be very grateful if people with the ability to compile from source code could test it to check for any significant bugs before release.

The code that I intend to make the next release, 10.4, is found on the running-powers branch of my Github repository.

The main new features are:
(1) players can now grant and withdraw access to other players (see the player menu), and so connect to other players' networks without using the public players;
(2) optionally, only the public player can use the "make public" tool;
(3) in addition to the way toll set by running costs of vehicles or way costs, there is a third option, being the way toll set by a fixed proportion of the revenue per tile of that player's way that the convoy has traversed; and
(4) the player colour is now saved with a saved game and transmitted over the network.

It also includes all of the latest updates in Standard. I should be very grateful for any feedback or testing before I release. Thank you in advance!

[dustNbone]

Did a quick Linux32/SDL build here, seems to segfault about 20 seconds after loading whether I load a map or not.  I'll rebuild with debug enabled and try have a better look later tonight.  Project seems to be rolling forward pretty quick these days.  Good work.

Dustin

[jamespetts]

Hmm - what pakset were you using? I don't get that error.

[wlindley]

Works OK for me, on Linux 64-bit.

For those wondering, "How do I know what branches are available, and how do I go get one?" I wrote a quick reference here.  Git is nice, but a little confusing after svn for so long!

[dustNbone]

I'm using Pak128.Britain 0.8.2, I'll try a couple others.

EDIT: Seems to happen with all 0.8.x versions of Pak128.Britain.exp but Pak64.Exp seems to load

[jamespetts]

Hmm - that's odd: 0.8.2 works fine for me on a release build. Are you sure that you are using the running-powers branch, not, say, the revenue-sharing branch?

[dustNbone]

I built from commit 7c9024f which I believe is the correct one.  It's odd because the build environment and configuration is the same one I've used for all previous ST builds.  That box did get new RAM last week, that's the only thing that's changed so I kind of suspect that.  It's been rock solid for a week but these things do happen.

[jamespetts]

Hmm - a reliable segfault running one specific program is very unlikely to be RAM. Are you using a 32-bit or 64-bit build?

Edit: 7c9024f24c is indeed the correct commit. Very odd.

[dustNbone]

It's 32bit build in a 32bit environment.  If anyone has another Linux32 build they could post I'd be interested in trying that.

[jamespetts]

Can you see if you can get a backtrace? My Win32-bit build (on a Windows 7 64 bit machine) works fine.

[wlindley]

...Hmm, correction: on Linux64, everything works fine for quite a long time... until I give another player access to my ways -- then a few seconds later, Segfault.

[jamespetts]

Hmm - can you get a backtrace?

[dustNbone]

Here is my terminal output:

Reading speedbonus configuration ...
Reading private car ownership configuration ...
Reading electricity consumption configuration ...
Reading menu configuration ...
Reading object data from Pak128.Britain-Ex-0.8.2/...
Loaded /home/dustin/simutrans10/Pak128.Britain-Ex-0.8.2/sound/aircraft-jet_stop.wav to sample 11.
Reading menu configuration ...
Midi disabled ...
World destroyed.
Calculating textures ...done
Loading BDF font 'font/Prop-Latin1.bdf'
Loading BDF font font/Prop-Latin1.bdf with 256 characters
Show banner ...
Running world, pause=0, fast forward=0 ...
World destroyed.
Calculating textures ...done
Segmentation fault

[jamespetts]

Hmm - that doesn't narrow it down much, I'm afraid. Are you able to compile with debug symbols and get a backtrace?

[wlindley]

I also see a problem with ships: This one is set to wait for 10% load, and it's at 27% load already but with 6311 hours remaining to board?

[jamespetts]

Can you upload a saved game?

[dustNbone]

Hmm - that doesn't narrow it down much, I'm afraid. Are you able to compile with debug symbols and get a backtrace?

I recompiled with debug=3, installed nemiver (gtk based debugger) and that's about as far as I can get.  I don't know how to generate a backtrace.  I can run the program in the debugger, it shows me "disassembly" output, and the segfault gets caught, but I'm not sure what information is important to you and how to get it.  I'm not a developer

[sdog]

segfault:
open player screen as player 1, check running powers button for other player LBSCR, cycle through players with P, crash when player LBSCR is reached.

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x00000000ffffffff in ?? ()
(gdb) bt
#0  0x00000000ffffffff in ?? ()
#1  0x000000000062ce2e in karte_t::interactive(unsigned int) ()
#2  0x00000000005d9ad3 in simu_main(int, char**) ()
#3  0x000000000040939c in main ()



sending a couple of boats to depot via 'retire' button caused some of the boats to enter the depot and others to wait infinitely at the quay. The game froze to death. (likely related to your teleportation issues?)

[sdog]

allow other player to acces ways (first checkbox) and then uncheck it again "withdraw access" => segfault

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x0000000000000071 in ?? ()
(gdb) bt
#0  0x0000000000000071 in ?? ()
#1  0x00000000006151b9 in karte_t::local_set_werkzeug(werkzeug_t*, spieler_t*)
   ()
#2  0x000000000051adbc in ki_kontroll_t::action_triggered(gui_action_creator_t*, value_t) ()
#3  0x00000000004a4c98 in button_t::infowin_event(event_t const*) ()
#4  0x00000000004f140d in gui_container_t::infowin_event(event_t const*) ()
#5  0x00000000004f28f9 in gui_frame_t::infowin_event(event_t const*) ()
#6  0x000000000060bf35 in check_pos_win(event_t*) ()
#7  0x000000000062bf25 in karte_t::interactive(unsigned int) ()
#8  0x00000000005d9ad3 in simu_main(int, char**) ()
#9  0x000000000040939c in main ()


switching to public player and withdrawing acces to player one does not crash the program.

but allowing him access to public ways again does segfault in the same way.

Code Select Expand



Program received signal SIGSEGV, Segmentation fault.
0x0000250529242d24 in ?? ()
(gdb) bt
#0  0x0000250529242d24 in ?? ()
#1  0x00000000006151b9 in karte_t::local_set_werkzeug(werkzeug_t*, spieler_t*)
    ()
#2  0x000000000051adbc in ki_kontroll_t::action_triggered(gui_action_creator_t*, value_t) ()
#3  0x00000000004a4c98 in button_t::infowin_event(event_t const*) ()
#4  0x00000000004f140d in gui_container_t::infowin_event(event_t const*) ()
#5  0x00000000004f28f9 in gui_frame_t::infowin_event(event_t const*) ()
#6  0x000000000060bf35 in check_pos_win(event_t*) ()
#7  0x000000000062bf25 in karte_t::interactive(unsigned int) ()
#8  0x00000000005d9ad3 in simu_main(int, char**) ()
#9  0x000000000040939c in main ()


[sdog]

There's a problem with pax walking to a nearby station. This already was present in 10.3.


Pax bunch up at a station (LNWR Brentchester Townhall Stop) with the via destination of another station they can only reach by walking:
(Brentchester Monument Stop). The walking connection is visible. The via station is not overcrowded. The Pax still do bunch up though. The numbers get gradually lower, but i can't see if this is for pax timing out or leaving in small bunches to the other station.

At some point all pax reroute to get to a different via station. (In this case the more direct way would have been two railway termini on either side of a road. After both station got massively overcrowded with people wanting to get to the other station, routing tried to move them in a different way (eg. this 'bus-stop)

My guess is, that is not a bug per-se, but you might have coded limits for the number of pax per unit of time to walk to another station? The route finder doesn't know it, and still routes them over this bottleneck. In my case it led to the yellow boating company to almost go bankrupt since the pax they transported timed out in their station and they did not get new pax from the other network. (The opposing stations are the interface between a large rail network and a small boating network.)

[sdog]

the fourth thread, for fourth independent finding:

in my saved game from 10.3 all my companies operate at a massive loss. For some reason revenues are close to zero, on a first glance it looks like refunds completely eat up revenues.

[jamespetts]

Sdog,

can you upload the saved game that you are using for this? There is no limit on the number of passengers per unit of time who may walk to another station, so I am not quite sure what the problem with the walking is. Allowing/denying access does not cause crashes on my machine, but I have not tried with your saved game (as I do not have it). Are you running 32- or 64-bit Linux?

Also, your backtraces suggest that the problem is somewhere in the code for the tool for setting the access rights in the second two examples, but provide no clue of where the problem might be in the first.

Sending things to the depot manually should not have changed, as the teleporting code is only invoked where a vehicle is stuck at "no route" for a certain amount of time, or has no stops in its schedule.

dustNbone,

can you tell me at what line of code (file name and line number) that the segfault is caught when you run the program in a debugger? If you are not given this information, can you compile with optimisations off and try again? Thank you very much!

Edit: As to the revenue problems - the issue appears to arise from the accumulated distance being recorded erroneously as zero in many cases, but I cannot find the source of this problem yet: it is quite hard to track down, since the distance is inserted into a hashtable at one point and extracted much later, and, worse, I have been unable to reproduce the problem on a map with just one convoy.

[dustNbone]

Sorry for the delay, got a little busy this weekend.  It seems to reliably croak on line 160 of simconvoi.h which reads :

accumulated_distance_since_departure[player] += steps;

Hope this is helpful

[jamespetts]

Hmm - I do wish that I could reproduce it and see it in a debugger myself, as it's rather hard to debug by correspondence. Does your debugger allow you to check values of the various variables? For example, can you let me know what the value of "player" is, and also the value of "this"? Are you sure that it is a segfault, rather than, say, an uninitialised variable?

[dustNbone]

Heh I feel your pain.  I wish it just worked   Anyway, the terminal output says "Segmentation Fault", and the debugger says the same, so I guess that's what it is.  As to the variables, "this" is 0x1847 and "player" is 1 '\
' (theres some weird character in there).  Noone else is having these or similar issues, I'm really suspecting my environment.

[jamespetts]

Hmm - it doesn't by any chance give the memory address of the variable that it was trying to read or write, does it, or tell you whether the error occurred in reading or writing that variable?

[Milko]

Hello

EDIT: Seems to happen with all 0.8.x versions of Pak128.Britain.exp but Pak64.Exp seems to load

The problem occurs again deleting demo.sve?

Giuseppe

[jamespetts]

Giuseppe,

thank you for thinking of that - yes, can people please delete demo.sve and try again. If it works with demo.sve deleted, can people try then to load another saved game and see whether the same problem recurs? Thank you.

Incidentally, I am currently working on the revenue issue. I have found part of the problem, which I have fixed on the revenue-sharing branch (and merged that with the running-powers branch), but the revenue is still too low. I shall keep trying to find a solution as I have time (although I now no longer have much left this week-end), but if anyone could look into the code, I should be most grateful.

The problem is partly related to the "distance" value at line 3960 of simconvoi.cc being incorrectly read as zero in some cases (resulting from the hashtable being asked to produce a value for which it has no key), although that is not enough to account for the majority of the issue that occurs at present (and might have been solved by my previous fix - it is hard to tell whether the few occasions on which it now occurs are residual from old saved games or not). The problem cannot be the apportionment of revenue between ways itself, as that would not show as a reduction in revenue, but rather a cost booked under "access charges".

Edit: Having tested, the remaining problems with the distance value are minimal, and the revenue loss goes beyond whatever may be caused by such residual issues are remaining. To deal with the residual issues, however, I have pushed a further fix to guess a reasonable value whenever the distance is read as zero. I shall not have time this week-end to find the remaining problem - but if anybody would like to try, I should be most grateful.

[sdog]

the walking to next station problem should be present in the save in this posting:
http://forum.simutrans.com/index.php?topic=8283.msg78301#msg78301

the other errors described are independent of pak-set.

[Milko]

Hello

I have compiled a windows version updated to November 7.

http://simutrans-germany.com/files/upload/simutrans-experimental_1107.zip

Giusepp

[jamespetts]

Sdog,

thank you for that - I have found and fixed the walking problem, which was related to the absence of a check of whether passengers should be walking when they are re-routed. The fix is on the 10.x branch (and should be pulled through to the other branches shortly).

I shall now revert to looking into the revenue issue.

[jamespetts]

I am afraid that I am having some difficulty in tracking down the cause of the remaining difficulties with the revenue: I cannot seem to find a setup in which I can reliably produce a precise comparison of a single revenue calculation in which there is a difference between the two versions. This is compounded by the fact that I cannot use the same saved game, as the save file format changes with the revenue-sharing branch. Any assistance would be much appreciated.

[jamespetts]

I have pushed a fix which should deal with the revenue problem: I should be grateful if people could re-test. It seems that the point to point journey times were calculated for the purpose of the revenue computation as being in tenths of minutes, but that the system for calculating the tolerable comfort assumed that they were calculated in whole minutes, thus giving greatly exaggerated figures for the tolerable comfort, and suppressing revenue.

Now, however, the revenue seems rather too high, although it is not entirely clear to me why that should be. I should be grateful if people could re-test the running-powers branch to check for any remaining difficulties.

Edit: I think that I have found the cause of the excess revenue (see pushes on the relevant branches), although I have not tested yet.

Edit 2: Also - I have pushed a few fixes for some of the crashes related to granting/withdrawing access. Can everybody re-test? Thank you very much, and apologies for the delay in making progress with this: the revenue bug was very hard to trace.

[jamespetts]

I was going to release to-day, but further testing seems to have revealed an extremely unfortunate problem: crashes on withdrawing access which only occur in an optimised release build, and which cannot therefore be trapped in a debugger. If anyone has any thoughts about how to resolve this seemingly intractable problem, I should be exceptionally grateful.

Edit: Eventually found and fixed - alas, too late for a release to-day.

[fbfree]

I also see a problem with ships: This one is set to wait for 10% load, and it's at 27% load already but with 6311 hours remaining to board?

I've seen this in 10.2 on linux 64 as well.  I was using an East Indiaman in pak-brit-exp 0.8.2.  The bug only happened when a ship moves a short distance (~ 1 tile) directly out of the depot to its first stop.