News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Command line server issues

Started by jamespetts, May 26, 2013, 10:50:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

In trying to test the server running the latest release candidate, I have found that the command line server (the version with no graphics) seems to have stopped working: although compiling it with the usual settings produces a valid executable, it fails on startup both on my Linux server and on Windows; the cause of the failure on Windows is not clear, but the Linux version complains at not being able to find ground.outside.pak and not being able to call a modal dialogue (which error is, from what I recall, the expected error if one starts a normal version with full graphics in a non-graphical environment). The Windows version just starts up and shuts down after a few seconds. When run as a server in the normal, full graphics mode (in Windows), it works fine and does not desync.

I am not entirely sure where to look to try to find this problem: I should be very grateful for any suggestions from anyone who has been working on the code recently, or might have an idea as to what could cause this sort of issue.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

#1
I have found that the crash occurs at line 149 of image_reader.cc. I wonder whether this could be anything to do with the integration of the world edge changes, as I have not touched the graphics code myself; does anyone know whether these changes affect image_reader.cc directly or indirectly?

Edit: Further tests show that it cannot be the map edge changes merged by Neroden, as the same error occurs in 10.9004. I wonder whether the issue might be related to this commit, which has been merged in since 10.27? Do any of the Standard developers have any idea what might cause an access violation in this code:

Quote// skip rest of the line
            do {
                dest++;
                dest += *dest + 1;
            } while (*dest);
            dest++;    // skip trailing zero

Edit 2: Further enquiry has shown that reverting this commit does not fix the problem, but rather moves the access violation to a different place:

Quote
#ifdef MULTI_THREAD
    // now the thread is finished ...
   EnterCriticalSection( &redraw_underway );
#endif

Does anyone have any clues about this one?

Edit 3: Disabling multi-threading, in Windows at least, by undefining MULTI_THREAD seems to fix the crash (setting MULTI_THREAD=0 has no effect), at least with the abovementioned commit reverted.

Edit 4: De-reverting the commit, whilst undefining MULTI_THREAD, however, does not work: the original crash still appears. There seem to be two separate, unrelated bugs here.

Edit 5: I notice in any event that my Linux build did not have MULTI_THREAD defined.

Edit 6: The debug output that I get from trying to run the command line server on Linux is:


...[lots of similar messages about vehicles' hashes]
Message: pakset_info_t::debug:  WagonLong -> sha1 = 964E308B68717BB634065A89659AF6548BB91889
Reading menu configuration ...
Warning: werkzeug_t::read_menu():       toolbar[11][5]: replaced way-builder(id=14) with default param=cityroad by cityroad builder(id=36)
Warning: ask_language:  No language selected, will use english!
loading savegame "upload-refresh.sve"
Midi disabled ...
Warning: karte_t::laden:        disconnecting all clients
Warning: nwc_routesearch_t::reset:      all static variables are reset
Warning: karte_t::laden():      Cannot load saved game!
Warning: nwc_routesearch_t::reset:      all static variables are reset
Message: grund_besch_t::calc_water_level():     Last image nr 1
Calculating textures ...done
Message: nwc_auth_player_t::init_player_lock_server:    new = 32767
Warning: karte_t::create_rivers():      Too many rivers requested! (only 0 rivers placed)
Creating cities ...
Creating cities: 1
Creating factories ...
Distributing 1 tourist attractions ...
Preparing startup ...
Warning: fabrikbauer_t::increase_industry_density():    No suitable city industry found => pak missing something?
Message: network_command_t::rdwr:       write packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr:      rdwr id=8 client=0 plnr=255 pos=koord3d invalid wkzid=8224 defpar=Now 0 clients connected. init=1 flags=0
ERROR: modal_dialogue():        called without a display driver => nothing will be shown!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
World destroyed.
Warning: nwc_routesearch_t::reset:      all static variables are reset


The actual error appears to be "ERROR: modal_dialogue():        called without a display driver => nothing will be shown!". It is not clear why this is being displayed, as COLOUR_DEPTH=0 is defined.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

About the linux server:

Warning: karte_t::laden:        disconnecting all clients
   -> tried starting loading a map
Warning: karte_t::laden():      Cannot load saved game!
  -> could not load (maybe the cityroad error?)

Not map loaded => create default world (next lines) and then show the banner window (which obviously could not be shown on the server). Hence the server works fine, but the savegame is broken.

jamespetts

Hmm - that's odd: the saved game works on my local copy. What is the highest debug level? Might a level higher than 3 give me more of a clue what is happening here?

Thank you very much for your reply.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

Extremely high debug levels generate some very frequent, very early output which prevents the game from really running, unfortunately; I found this out a while back.  You'll have to debug the debug code in order to use the high debug levels.

I just tested the command-line version of the server (from my 11x-fixes branch) on my savegame -- it works.

Your savegame is broken in some interesting way.  Have you tried loading it and re-saving it?

(The 112.x branch is probably broken because I know I screwed something up related to savegames in the accounting merger.)

neroden

Quote from: neroden on May 29, 2013, 02:13:18 AM
Your savegame is broken in some interesting way.  Have you tried loading it and re-saving it?

It is possible that it is broken for the same reason mine was broken.  (The "partial implementation" of the savefile format change.)  Have you tried applying the same fix?

jamespetts

Neroden,

thank you for testing this. Apologies for not having relied to this and other messages earlier: have been (and am still) away from home, so do not have full access to my development environment, although can log into my Linux server, as am staying with Parents, and have a Linux terminal set up here.

Starting with your most recent hypothesis, I tested this by running the original saved game from 10.27: if there was an issue with partial implementation of a new file format, this game would load without difficulty. This did not assist. The output that I got from that was:


[Lots of stuff about road rules, not reproduced here]
Reading speedbonus configuration ...
ReadiReading speedbonus configuration ...
Reading private car ownership configuration ...
Reading electricity consumption configuration ...
Reading menu configuration ...
Reading object data from Pak128.Britain-Ex-0.8.4/...
Reading menu configuration ...
loading savegame "upload-refresh.sve"
Midi disabled ...
Calculating textures ...done
Creating cities ...
Creating cities: 1
Creating factories ...
Distributing 1 tourist attractions ...
Preparing startup ...
World destroyed.
root@438242:/usr/share/games/simutrans-experimental/simutrans# ./simutrans-experimental -server -objects Pak128.Britain-Ex-0.8.4 -load pre-upgrade.sve -log 1 - debug 4 > test-problem.log
Simutrans version 112.2 Experimental Release Candidate 11.9006 from May 26 2013 r119006
root@438242:/usr/share/games/simutrans-experimental/simutrans# psng private car ownership configuration ...
Reading electricity consumption configuration ...
Reading menu configuration ...
Reading object data from Pak128.Britain-Ex-0.8.4/...
Reading menu configuration ...
loading savegame "upload-refresh.sve"
Midi disabled ...
Calculating textures ...done
Creating cities ...
Creating cities: 1
Creating factories ...
Distributing 1 tourist attractions ...
Preparing startup ...
World destroyed.


The same output was generated with the refreshed saved game saved in the new version. The intermediate save compatibility issue was not likely to be the issue in any event, as the game that I have uploaded to the server is a copy of a saved game that I can open without problems on my machine at home. Further, an archived 10.27 build can run the pre-upgrade game that I tested above without trouble.

I am wondering whether the problem might in part be some changes to the makefile that have occurred since 10.27: I notice that there must have been changes, as the default executable name has reverted to "sim" from the previous default of "simutrans-experimental".

I wonder whether you could upload your binary (if it is a 64-bit binary) to http://files.simutrans-germany.com so that I can test whether the problem is in my Linux build environment somewhere? That would at least go some way towards narrowing the problem.

Incidentally, what saved game do you use, and what command do you use to start the server?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

It is not loading your savegame, it is instead generating the default island at teh start. Is the savegame in the rigth folder  ~/simutrans/save/ ?

jamespetts

Ahh, no, it's not in ~/simutrans/save - it's just in ~/simutrans. Is the addition of /save in Linux fairly recent (after about February 2012)? 10.27 (based on Standard from February 2012) works with the saved games in ~/simutrans.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

#9
I have copied my executable into a working directory under a name based on the build date (so that I can compare several).

I use the command

./sim-20130601 -objects ./pak-20130601 -server 1234 -load test.sve


Yes, I think the relocation of save files to the "save" subdirectory is new since February.  In fact, I found that test.sve had to be in the directory:
~/.simutrans-ex/save/

Even if I had a different working directory for simutrans.  Which I do (I keep the executable and pak in ~/simutrans-ex-new ).

This may be what is giving you problems.

I think the directory search code should probably be cleaned up, but I haven't looked at it.

Vonjo

It looks like you want to load "pre-upgrade.sve", but simutrans-experimental tried to load "upload-refresh.sve".

jamespetts

#11
Hmm - I do not think that the saved game directory issue is the ultimate problem - I get the same problem:

Quote
Reading speedbonus configuration ...
Reading private car ownership configuration ...
Reading electricity consumption configuration ...
Reading menu configuration ...
Reading object data from ./Pak128.Britain-Ex-0.8.4/...
Reading menu configuration ...
loading savegame "upload-refresh.sve"
Midi disabled ...
Calculating textures ...done
Creating cities ...
Creating cities: 1
Creating factories ...
Distributing 1 tourist attractions ...
Preparing startup ...
ERROR: modal_dialogue():   called without a display driver => nothing will be shown!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
World destroyed.

when I expressly try to call a specific saved game from the command line using "-load upload-refresh.sve", and even copying upload-refresh.sve into ../simutrans-ex/save did not assist.

Edit: Having compiled a debug version and using debug level 4, this is the output that I get (warning: large file).

Edit 2: The very last part of that large file (for those who do not want to download the whole thing) reads as follows:


Message: network_http_post: received header: HTTP/1.1 202 Accepted
Message: network_http_post: received header: Content-Type: text/html
Message: network_http_post: received header: Date: Sat, 01 Jun 2013 13:37:39 GMT
Message: network_http_post: received header: Connection: keep-alive
Message: network_http_post: received header: Transfer-Encoding: chunked
Message: network_http_post: all headers received, message body follows
Message: network_http_post: 5
Message: network_command_t::rdwr: write packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr: rdwr id=8 client=0 plnr=255 pos=koord3d invalid wkzid=8224 defpar=Now 0 clients connected. init=1 flags=0
Debug: karte_t::step: end
Debug: karte_t::step: start step
Debug: karte_t::step: time calculations
Debug: interrupt_check: called from (simworld.cc:4150)
Debug: karte_t::step: pending_season_change. 4096 tiles.
Debug: interrupt_check: called from (simworld.cc:4161)
Debug: interrupt_check: called from (simworld.cc:4161)
Debug: interrupt_check: called from (simworld.cc:4161)
Debug: interrupt_check: called from (simworld.cc:4161)
Debug: interrupt_check: called from (simworld.cc:4172)
Debug: interrupt_check: called from (simworld.cc:4176)
Debug: karte_t::step 4: step 0 convois
Debug: karte_t::step 6: step cities
Debug: karte_t::step: step factories
Debug: karte_t::step: step poweline stuff
Debug: karte_t::step: step players
Debug: karte_t::step: step halts
Debug: interrupt_check: called from (simworld.cc:4243)
Debug: karte_t::step: end
Message: karte_t::reset_timer(): called, mode=$1
ERROR: modal_dialogue(): called without a display driver => nothing will be shown!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
Message: karte_t::destroy(): destroying world
Message: karte_t::destroy(): label clear
Message: karte_t::destroy(): convois destroyed
Message: karte_t::destroy(): stops destroyed
Message: karte_t::rem_stadt(): Coatwater
Debug: karte_t::rem_stadt(): reduce city to 0
Debug: karte_t::rem_stadt(): fab_list 4
Message: karte_t::rem_stadt(): delete
Message: karte_t::destroy(): towns destroyed
Message: karte_t::destroy(): sync list cleared
Message: karte_t::destroy(): planquadrat destroyed
Message: karte_t::destroy(): marker destroyed
Message: karte_t::destroy(): player destroyed
Message: karte_t::destroy(): factories destroyed
Message: karte_t::destroy(): attraction list destroyed
Message: karte_t::destroy(): world destroyed
World destroyed.
Warning: nwc_routesearch_t::reset: all static variables are reset
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

I still see
Creating cities: 1
Creating factories ...
Distributing 1 tourist attractions

That means the standard island is creating. i.e. your map is not loading. or generates an error during loading.

The save directory was needed since version 0.78 or so, even before my time as programmer. Just the path ~/simutrans/save/ for standard is newer, albeit not that new. Once sucessfully loaded, you should see a server13353-netowrk.sve as soon as somebody joined in the simutrans directory. (If simutrans experimental uses another directory, then obviously you need to use this.)

jamespetts

Am I correct, though, that server13353-network.sve does not load from the /save directory but from the same directory as the executable, and also that an explicit command "load -some-saved-game.sve" can specify the directory in which it is to be found?

I have been specifying -load ./upload-refresh.sve (for example) and still getting this error. It is most odd.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

TurfIt

No. You cannot change the save root like that. You may specify sub directories below save/ however.
-load aa/upload-refresh.sve   will load ~/simutrans/save/aa/up-refresh.sve (or ./simutrans/save/aa/up-refresh.sve in single_user mode)

The server13353-network ( and -client) saves do save outside save/ as special cases, but you must put them into save/ if you wish to load them manually.

jamespetts

#15
If that is so, my tests are not working, and there is an unidentified problem with the server, as it ought to be loading server13353.network.sve in any event (and, if I remember correctly, by default if I specify -server at the command line without also specifying -load?).

Edit: Also, this doesn't explain the problem, does it? Even if it creates the little test island, why should it have to display a modal dialogue?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

It may find an old version of the setting. Did you try to add "-lang en" on the commandline to avoid showing the language dialogue?

Well my server installation look like this:

~/src/simutrans/trunk/... <- here I compile etc.
~/simserv/ <- here are config dir, pak dir, executable ...
~/simutrans/save <- here goes the intial savegames
~/simutrans/pak/config/simuconf.tab <- here I put the savegame specific server settings
~/simutrans/ <- here the server123-network.sve, pashword hashes and logfiles will be created

The server is initialized by:
./simstable -server 65124 -log 1 -debug 3 -lang en -objects pak/ -nosound -nomidi -server_dns xyz.co.uk -load netzwerk7.sve -server_name "pak64 112.3 I" -server_admin_pw XXX &

jamespetts

Thank you for your help.

I had not previously tried "-lang en", but I have tried it, and sadly get the same result. The server was previously working with an automatic startup script when it was running 10.27, which does not work now, so the settings that I use cannot be the ultimate problem unless something has changed in how those settings are interpreted.

Incidentally, since I am staying with my parents and have access to a Linux desktop, I tried compiling it there; I had the same result as for the server running the no graphics version, and additionally, the program will crash when compiled in the normal graphics mode, with this backtrace:


Reading speedbonus configuration ...
Reading private car ownership configuration ...
Reading electricity consumption configuration ...
Reading menu configuration ...
Reading object data from /home/james/simutrans/Pak128.Britain-Ex-0.8.4/...

Program received signal SIGSEGV, Segmentation fault.
0x082902bc in display_set_base_image_offset (bild=1, xoff=11768, yoff=-16604) at simgraph16.cc:2005
2005        assert(images[bild].base_w > 0);
(gdb) backtrace
#0  0x082902bc in display_set_base_image_offset (bild=1, xoff=11768, yoff=-16604) at simgraph16.cc:2005
#1  0x08290aac in display_img_aux (n=0, xp=351, yp=139, use_player=0 '\000', dirty=1) at simgraph16.cc:2339
#2  0x08290d5d in display_color_img (n=0, xp=351, yp=139, player_nr=0 '\000', daynight=0, dirty=1) at simgraph16.cc:2413
#3  0x082aed7f in loadingscreen_t::display_logo (this=0xbfffcf70) at simloadingscreen.cc:54
#4  0x082aec6d in loadingscreen_t::loadingscreen_t (this=0xbfffcf70, w=0x8384373 "Loading paks ...", max_p=28, logo=true,
    continueflag=false) at simloadingscreen.cc:37
#5  0x080807ce in obj_reader_t::load (path=0x855c8ec "/home/james/simutrans/Pak128.Britain-Ex-0.8.4/", message=0x8384373 "Loading paks ...")
    at besch/reader/obj_reader.cc:144
#6  0x082b2060 in simu_main (argc=1, argv=0xbffff364) at simmain.cc:952
#7  0x082c0dff in sysmain (argc=1, argv=0xbffff364) at simsys.cc:703
#8  0x08353e09 in main (argc=1, argv=0xbffff364) at simsys_s.cc:623


Most perplexing.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vonjo

Confirmed.
Even running it with only:
$ ./sim -objects pak/
...does not work. It returns the same modal_dialogue() error.

The graphics version (simgraph16.cc) works fine for me though.

jamespetts

Vonjo,

thank you for testing. How did you compile your graphics version?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vonjo

Further investigation reveals that the modal_dialogue() error also occurs with simutrans-standard when there is no -load command line switch provided.
So I tried this:
$ ./sim -server -objects pak/ -load abc.sve
...and it works fine. I can join the server and play.
It looks like the problem is related to your savegame or directory structure.

Quote from: jamespetts on June 03, 2013, 11:22:31 AM
Vonjo,

thank you for testing. How did you compile your graphics version?
ostype=linux
color_depth=16
backend=mixer_sdl
debug=3
optimize=1
multi_thread=4

jamespetts

Thank you very much for testing. Would you mind trying again with a version compiled without MULTI_THREAD defined, and let me know how you get on?

Edit: Also, can you give me your compile settings for the no graphics version?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vonjo

Ok, I may try it later.
Quote from: jamespetts on June 03, 2013, 04:30:47 PM
Edit: Also, can you give me your compile settings for the no graphics version?
The settings are the same as the graphics version, but with backend posix and color_depth 0.

neroden

The problem is definitely in the savegame or the directory structure.  And yes, something changed in the last six months regarding how those are interpreted.  I'm not sure exactly what. 

jamespetts

Thank you for your help, both of you. I have found the error in my locally compiled normal graphics version: I used "SDL" instead of "SDL_MIXER". What, I wonder, is straight "SDL" for?

As to the loading of saved games from the command line, now that I am able to get a normal graphics version running, I have been able to test this. Loading a previous server saved game (server13353-network.sve from the 24th of December last year, which is from the Bridgewater-Brunel online game), it gave me a fatal error message that a certain industry (sometimes a greengrocer, other times a power station) could not be located on the map: this was from the recalc_nearby_halts method. I strongly suspect that it is the inability to display this fatal error message that is causing the exiting in the non-graphics version: in effect, the ultimate problem is the trigger of this crash; but it is not something that I have been able to recreate in my Windows debugger back home.

This also points to a possible design issue with error messages: in the no graphics version, where a fatal error message is to be displayed, this should be done by text ouput to the command line rather than by generating an error that it cannot display a modal dialogue.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

SDL was the original version. SDL_Mixer adds support from playing midi files (or indeed, other sound files) as music. If you don't need that plain SDL will be fine.

jamespetts

Hmm - I wonder why plain SDL crashes, then?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

Quote from: jamespetts on June 03, 2013, 11:48:16 PM
This also points to a possible design issue with error messages: in the no graphics version, where a fatal error message is to be displayed, this should be done by text ouput to the command line rather than by generating an error that it cannot display a modal dialogue.
This would be a definite improvement!

Actually, for various reasons, even in the graphical version I'd like to see fatal errors sent to the command line as well as to a modal dialogue; sometimes the modal dialogue is obscured and goes away (when the game subsequently crashes, for example), and so it's much easier for debugging to look at the command line.

This is how I'd have it work: the error should always go to the command line, and in addition it should go to the modal dialogue if graphics are enabled.

---
Regarding the failure with plain SDL, this *is* interesting.

The main differences in the Makefile are these.  mixer_sdl has:
  SOURCES += sound/sdl_mixer_sound.cc
  SOURCES += music/sdl_midi.cc
While plain sdl on Linux has:
    SOURCES  += sound/sdl_sound.cc
    SOURCES += music/no_midi.cc

(Now, plain SDL has different behavior on mac, cygwin, and mingw, so if you compiled a windows version, there's more going on.)
These aren't very different, so I'm startled that it is causing a crash.

kierongreen

Plain SDL only uses SDL for video - music is played using windows routines (if on Linux/Mac then it is disabled). SDL_Mixer uses SDL to play music on all platforms.

jamespetts

Hmm, all very curious.

Nathaneal - any thoughts on why it fails in recalc_nearby_halts when loading from the command line?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

#30
I have been spending some time looking into this to-day. I have made progress, but do not have a full resolution yet. Firstly, the problem with loading saved games manually on the command line was caused by the /save directory thing, but the problem with the automatic loading was not caused by this, as the automatic server saved game is still stored in the base directory. This problem was caused by a loading bug (the ultimate cause of which is still not clear to me) which I have fixed on the 11.x branch.

However, a new problem emerges. The server - but only the Linux command line server, not a server running in Windows or the client running in Windows (I have not had the chance to test a Linux client) crashes on a new month in the current Bridgewater-Brunel saved game. The backtrace is as follows:



Program received signal SIGSEGV, Segmentation fault.
0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
242             inline typ get_typ() const { return type; }
(gdb) net:br
Undefined command: "net".  Try "help".
(gdb) backtrace
#0  0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
#1  0x0000000000464af8 in bsearch_dings_by_prio (pri=200, dings=0x11a982e8, count=4) at dataobj/dingliste.cc:454
#2  0x0000000000464cc4 in dingliste_t::add (this=0x11746650, ding=0x348a5260) at dataobj/dingliste.cc:501
#3  0x0000000000408a6d in grund_t::obj_add (this=0x11746648, obj=0x348a5260) at bauer/../boden/grund.h:521
#4  0x0000000000710175 in vehikel_t::rauche (this=0x2cb95ac0) at vehicle/simvehikel.cc:1854
#5  0x000000000064ac57 in convoi_t::sync_step (this=0x2cb940c0, delta_t=83) at simconvoi.cc:1141
#6  0x00000000006e727d in karte_t::sync_step (this=0x1576380, delta_t=83, sync=true, display=true) at simworld.cc:3450
#7  0x00000000006f7ed9 in karte_t::interactive (this=0x1576380, quit_month=2147483647) at simworld.cc:7106
#8  0x000000000069b308 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#9  0x00000000006aaecd in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#10 0x000000000074d852 in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147
(gdb)


Any thoughts as to what could be causing this would be most appreciated whilst I continue my investigations.

Edit: The problem appears to occur in the code for vehicle smoke. Strictly, this is not needed in a no-graphics server implementation; but is it safe simply to do this:

void vehikel_t::rauche() const
{
#if COLOUR_DEPTH == 0
    // We do not need smoke if there are no graphics.
    return;
#else
    // raucht ueberhaupt ?
    if(  rauchen  &&  besch->get_rauch()  ) {


or will the differing number of objects on a tile possibly cause desynchronisation?

Edit 2: Having tested, not only does this change cause desynchronisation, it also fails to fix the crash. I now get:


Program received signal SIGSEGV, Segmentation fault.
0x0000000000462baa in ding_t::is_moving (this=0x0) at dataobj/../vehicle/../boden/../dataobj/../simdings.h:188
188             inline bool is_moving() const { return flags&is_vehicle; }
(gdb) backtrace
#0  0x0000000000462baa in ding_t::is_moving (this=0x0) at dataobj/../vehicle/../boden/../dataobj/../simdings.h:188
#1  0x0000000000709c8f in ding_cast<vehikel_basis_t> (d=0x0) at vehicle/../vehicle/simvehikel.h:198
#2  0x000000000070b755 in vehikel_basis_t::no_cars_blocking (this=0x2bbf3a10, gr=0x11747de8, cnv=0x2bbf1ff0,
    current_fahrtrichtung=4 '\004', next_fahrtrichtung=12 '\f', next_90fahrtrichtung=8 '\b') at vehicle/simvehikel.cc:620
#3  0x00000000007151fa in automobil_t::ist_weg_frei (this=0x2bbf3a10, restart_speed=@0x7fffffffb680: -1, second_check=false)
    at vehicle/simvehikel.cc:3006
#4  0x000000000064ca63 in convoi_t::step (this=0x2bbf1ff0) at simconvoi.cc:1610
#5  0x00000000006ea934 in karte_t::step (this=0x1575380) at simworld.cc:4189
#6  0x00000000006f7f3d in karte_t::interactive (this=0x1575380, quit_month=2147483647) at simworld.cc:7113
#7  0x000000000069b308 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#8  0x00000000006aaecd in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#9  0x000000000074d57e in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147


Edit 3: Hmm - this seems inconsistent. I reverted the above change and ran again. At the month boundary, it desynched (as it often does at month boundaries). On reconnecting from the client (but not before), I had this error on the server (which is set to pause when no clients are connected):



Program received signal SIGSEGV, Segmentation fault.
0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
242             inline typ get_typ() const { return type; }
(gdb) backtrace
#0  0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
#1  0x00000000004669d0 in dingliste_t::rdwr (this=0x68eef20, welt=0x1576380, file=0x7fffffffb450, current_pos=...)
    at dataobj/dingliste.cc:1062
#2  0x00000000004532b2 in grund_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/grund.cc:368
#3  0x0000000000450f89 in boden_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/boden.cc:55
#4  0x00000000006a7ff0 in planquadrat_t::rdwr (this=0x7ffff0e5a9d8, welt=0x1576380, file=0x7fffffffb450, pos=...)
    at simplan.cc:240
#5  0x00000000006ee331 in karte_t::save (this=0x1576380, file=0x7fffffffb450, silent=false) at simworld.cc:4972
#6  0x00000000006eda05 in karte_t::save (this=0x1576380, filename=0x7fffffffb770 "server13353-network.sve",
    savemode=loadsave_t::zipped, version_str=0x759a25 "0.112.4", ex_version_str=0x759a21 ".11", silent=false)
    at simworld.cc:4848
#7  0x0000000000485991 in nwc_sync_t::do_command (this=0x348b4d90, welt=0x1576380) at dataobj/network_cmd_ingame.cc:730
#8  0x00000000006f7cb5 in karte_t::interactive (this=0x1576380, quit_month=2147483647) at simworld.cc:7062
#9  0x000000000069b308 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#10 0x00000000006aaecd in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#11 0x000000000074d852 in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147
(gdb)


Edit 4: I noticed in that last backtrace that some of the pointers appeared to be of 32-bit length, so I added the -m64 and -mtune=native options to the build command in config.default. It did not desync at the end of the month, but crashed very shortly thereafter (circa 30-40 game seconds later) with this:


Program received signal SIGSEGV, Segmentation fault.
0x0000000000462baa in ding_t::is_moving (this=0x0) at dataobj/../vehicle/../boden/../dataobj/../simdings.h:188
188             inline bool is_moving() const { return flags&is_vehicle; }
(gdb) backtrace
#0  0x0000000000462baa in ding_t::is_moving (this=0x0) at dataobj/../vehicle/../boden/../dataobj/../simdings.h:188
#1  0x00000000004645e2 in dingliste_t::intern_add_moving (this=0xe520390, ding=0x2ba3b500) at dataobj/dingliste.cc:293
#2  0x0000000000464c14 in dingliste_t::add (this=0xe520390, ding=0x2ba3b500) at dataobj/dingliste.cc:488
#3  0x0000000000408a6d in grund_t::obj_add (this=0xe520388, obj=0x2ba3b500) at bauer/../boden/grund.h:521
#4  0x000000000070aa65 in vehikel_basis_t::betrete_feld (this=0x2ba3b500) at vehicle/simvehikel.cc:302
#5  0x000000000070ebab in vehikel_t::betrete_feld (this=0x2ba3b500) at vehicle/simvehikel.cc:1396
#6  0x000000000071b3ad in waggon_t::betrete_feld (this=0x2ba3b500) at vehicle/simvehikel.cc:4268
#7  0x000000000070f00d in vehikel_t::hop (this=0x2ba3b500) at vehicle/simvehikel.cc:1441
#8  0x000000000070abd7 in vehikel_basis_t::fahre_basis (this=0x2ba3b500, distance=4096) at vehicle/simvehikel.cc:347
#9  0x000000000064abb3 in convoi_t::sync_step (this=0x2ba39230, delta_t=83) at simconvoi.cc:1131
#10 0x00000000006e727d in karte_t::sync_step (this=0x1576380, delta_t=83, sync=true, display=true) at simworld.cc:3450
#11 0x00000000006f7ed9 in karte_t::interactive (this=0x1576380, quit_month=2147483647) at simworld.cc:7106
#12 0x000000000069b308 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#13 0x00000000006aaecd in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#14 0x000000000074d852 in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147


Edit 5: This problem seems curiously inconsistent: running again without rebuilding either server or client, I get a desync at the month boundary, and this error on reconnecting:



Program received signal SIGSEGV, Segmentation fault.
0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
242             inline typ get_typ() const { return type; }
(gdb) backtrace
#0  0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
#1  0x00000000004669d0 in dingliste_t::rdwr (this=0x68eef20, welt=0x1576380, file=0x7fffffffb450, current_pos=...)
    at dataobj/dingliste.cc:1062
#2  0x00000000004532b2 in grund_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/grund.cc:368
#3  0x0000000000450f89 in boden_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/boden.cc:55
#4  0x00000000006a7ff0 in planquadrat_t::rdwr (this=0x7ffff0e5a9d8, welt=0x1576380, file=0x7fffffffb450, pos=...)
    at simplan.cc:240
#5  0x00000000006ee331 in karte_t::save (this=0x1576380, file=0x7fffffffb450, silent=false) at simworld.cc:4972
#6  0x00000000006eda05 in karte_t::save (this=0x1576380, filename=0x7fffffffb770 "server13353-network.sve",
    savemode=loadsave_t::zipped, version_str=0x759a25 "0.112.4", ex_version_str=0x759a21 ".11", silent=false)
    at simworld.cc:4848
#7  0x0000000000485991 in nwc_sync_t::do_command (this=0x2be68500, welt=0x1576380) at dataobj/network_cmd_ingame.cc:730
#8  0x00000000006f7cb5 in karte_t::interactive (this=0x1576380, quit_month=2147483647) at simworld.cc:7062
#9  0x000000000069b308 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#10 0x00000000006aaecd in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#11 0x000000000074d852 in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147
(gdb)


Edit 6: Adding checks for NULL at the appropriate lines (see the latest commit on the 11.x branch) has not fixed this issue: I now get this crash:


Program received signal SIGSEGV, Segmentation fault.
0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
242             inline typ get_typ() const { return type; }
(gdb) backtrace
#0  0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
#1  0x0000000000466a18 in dingliste_t::rdwr (this=0x68eef20, welt=0x1576380, file=0x7fffffffb450, current_pos=...)
    at dataobj/dingliste.cc:1062
#2  0x00000000004532b2 in grund_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/grund.cc:368
#3  0x0000000000450f89 in boden_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/boden.cc:55
#4  0x00000000006a8038 in planquadrat_t::rdwr (this=0x7ffff0e5a9d8, welt=0x1576380, file=0x7fffffffb450, pos=...)
    at simplan.cc:240
#5  0x00000000006ee379 in karte_t::save (this=0x1576380, file=0x7fffffffb450, silent=false) at simworld.cc:4972
#6  0x00000000006eda4d in karte_t::save (this=0x1576380, filename=0x7fffffffb770 "server13353-network.sve",
    savemode=loadsave_t::zipped, version_str=0x759a85 "0.112.4", ex_version_str=0x759a81 ".11", silent=false)
    at simworld.cc:4848
#7  0x00000000004859d9 in nwc_sync_t::do_command (this=0x2cb64cb0, welt=0x1576380) at dataobj/network_cmd_ingame.cc:730
#8  0x00000000006f7cfd in karte_t::interactive (this=0x1576380, quit_month=2147483647) at simworld.cc:7062
#9  0x000000000069b350 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#10 0x00000000006aaf15 in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#11 0x000000000074d89e in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147


Edit 7: Running again for consistency checking produces this error (again on reload after desync):


Program received signal SIGSEGV, Segmentation fault.
0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
242             inline typ get_typ() const { return type; }
(gdb) backtrace
#0  0x00000000004340f0 in ding_t::get_typ (this=0x0) at bauer/../boden/../dataobj/../simdings.h:242
#1  0x0000000000466a18 in dingliste_t::rdwr (this=0x68eef20, welt=0x1576380, file=0x7fffffffb450, current_pos=...)
    at dataobj/dingliste.cc:1062
#2  0x00000000004532b2 in grund_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/grund.cc:368
#3  0x0000000000450f89 in boden_t::rdwr (this=0x68eef18, file=0x7fffffffb450) at boden/boden.cc:55
#4  0x00000000006a8038 in planquadrat_t::rdwr (this=0x7ffff0e5a9d8, welt=0x1576380, file=0x7fffffffb450, pos=...)
    at simplan.cc:240
#5  0x00000000006ee379 in karte_t::save (this=0x1576380, file=0x7fffffffb450, silent=false) at simworld.cc:4972
#6  0x00000000006eda4d in karte_t::save (this=0x1576380, filename=0x7fffffffb770 "server13353-network.sve",
    savemode=loadsave_t::zipped, version_str=0x759a85 "0.112.4", ex_version_str=0x759a81 ".11", silent=false)
    at simworld.cc:4848
#7  0x00000000004859d9 in nwc_sync_t::do_command (this=0x2cb77df0, welt=0x1576380) at dataobj/network_cmd_ingame.cc:730
#8  0x00000000006f7cfd in karte_t::interactive (this=0x1576380, quit_month=2147483647) at simworld.cc:7062
#9  0x000000000069b350 in simu_main (argc=8, argv=0x7fffffffe568) at simmain.cc:1245
#10 0x00000000006aaf15 in sysmain (argc=8, argv=0x7fffffffe568) at simsys.cc:703
#11 0x000000000074d89e in main (argc=8, argv=0x7fffffffe568) at simsys_posix.cc:147
(gdb)
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Either your game is broken or the version has some serious problems. "this=0x0" means you are accessing an initialized pointer.

jamespetts

It is the latter, I fear, as I have tested the game in Windows without difficulty: but I cannot work out why these problems only show themselves at the end of a month on a Linux server. It is quite the mystery.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

*Sigh*.  There's definitely a dangling pointer of some sort.  I hate that sort of error.

I particularly couldn't tell you what's wrong given that I've been having no problems with the full-graphics Linux version, even over many months.

I strongly suspect that saved game corruption is involved.  Have you had trouble with anything other than the Bridgewater-Brunel game?  Can you get it to run for long periods using a different saved game?  Try a brand new game; also try a game originally from Standard.

jamespetts

Thank you for the suggestions. There is definitely something going wrong somewhere with memory management: null pointers suddenly pop up all over the place where they don't in a normal full graphics version. What I don't understand is why this happens only: (1) in a command line server version; (2) after a month boundary; and (3) in code that has never been touched by Experimental specific code (at least anywhere near directly). You may recall that I earlier had trouble with access violations in a totally different place when running the Windows command line server.

As to saving games; I did send a force-sync command with nettool, and this worked, and the saved game produced by that command is perfectly loadable and works fine. I also have no trouble with the Bridgewater-Brunel saved game either in earlier versions or in a full graphics client.

However, I will try a Standard save to eliminate this issue and post the result if you think that that would help to eliminate the saved game itself as an issue.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.