[crash devel] elevated tracks with stations, crash on weight check

[sdog]

the crash can be reproduced by building elevated rails (pak britain viaducts), putting a station on them, as soon as a train calls to the station the crash happens. Pure elevated rails without stop/station does not cause the crash in several tests. Saving before a train arrives also prevents the crash.

Code Select Expand

Program received signal SIGSEGV, Segmentation fault.
0x000000000044bdc4 in weg_t::get_max_weight (this=0x0)
   at boden/../boden/wege/weg.h:193
193 uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044bdc4 in weg_t::get_max_weight (this=0x0)
   at boden/../boden/wege/weg.h:193
#1  0x000000000064cd4f in waggon_t::ist_befahrbar (this=0x9582f30,
   bd=0x57dd128) at vehicle/simvehikel.cc:2927
#2  0x00000000006452e9 in vehikel_t::hop_check (this=0x9582f30)
   at vehicle/simvehikel.cc:1157
#3  0x00000000006423c7 in vehikel_basis_t::fahre_basis (this=0x9582f30,
   distance=92082) at vehicle/simvehikel.cc:303
#4  0x00000000005a746e in convoi_t::sync_step (this=0x95828b0, delta_t=100)
   at simconvoi.cc:660
#5  0x0000000000622a69 in karte_t::sync_step (this=0x11fd240, delta_t=100,
   sync=true, display=false) at simworld.cc:2766
#6  0x000000000062f51c in karte_t::interactive (this=0x11fd240,
   quit_month=2147483647) at simworld.cc:5764
#7  0x00000000005e509b in simu_main (argc=1, argv=0x7fffffffe2d8)
   at simmain.cc:1076
#8  0x0000000000669392 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749


i thought i reported it earlier, but couldn't find the thread anymore.

[jamespetts]

I can't reproduce this, I'm afraid. Could you upload a saved game?

[sdog]

FIX: Speculative fix for reported crash that I cannot reproduce.

i'll test it momentarily

crashed, already when running over a normal viaduct

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x000000000044c008 in weg_t::get_max_weight (this=0x0)
   at boden/../boden/wege/weg.h:193
193 uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044c008 in weg_t::get_max_weight (this=0x0)
   at boden/../boden/wege/weg.h:193
#1  0x000000000064e564 in waggon_t::ist_befahrbar (this=0x9754a70,
   bd=0x569a088) at vehicle/simvehikel.cc:2933
#2  0x0000000000646a11 in vehikel_t::hop_check (this=0x9754a70)
   at vehicle/simvehikel.cc:1157
#3  0x0000000000643aef in vehikel_basis_t::fahre_basis (this=0x9754a70,
   distance=106951) at vehicle/simvehikel.cc:303
#4  0x00000000005a83d6 in convoi_t::sync_step (this=0x9754430, delta_t=100)
   at simconvoi.cc:660
#5  0x0000000000623eff in karte_t::sync_step (this=0x137a060, delta_t=100,
   sync=true, display=false) at simworld.cc:2765
#6  0x0000000000630c42 in karte_t::interactive (this=0x137a060,
   quit_month=2147483647) at simworld.cc:5776
#7  0x00000000005e5fd7 in simu_main (argc=1, argv=0x7fffffffe2d8)
   at simmain.cc:1076
#8  0x000000000066ae76 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749


I've overlooked something important before, which also explains why the bug does not happen after saving the game.

To cause the crash, the elevated track must be built after the train has calculated it's route already.
Recipe to cause the crash:
- build a lenght of track with two stations,
- let a train run between them.
- while the train leaves one of the stations pause the game
  the timing is critical here, i think the change has to be built during the trains route finding.
  a good time seems to pause is just after the train is reversed.
- remove a few pieces of track
- build the elevated way and connect it with bridge parts
- wait for the train to come.

There are some other conditions i couldn't quite understand, since this recipe does not produce the crash for some cases. It worked for 75 km/h 61 t wooden sleeper track, 3 tiles elevated way of 80t type, and 136 t brick railway viaduct. Runing a M7 steam loc with one carriage. It did never crash when i tested with a 100t diesel engine on heavy weight modern tracks/viaducts. Perhaps certain weight ratios must be given.

Some more trying, i couldn't get it to crash whatever i did, with the above setup. But on other occasions it crashed whener i did something.
It is sometimes visible that the train changes it's position (tank engines get turned around!) when it notices that the track has changed. In that case nothing happens. But sometimes it gets overlooked, the train just goes on the viaduct and the program crashes.

when pausing and changing the track right after the train reversed in a station, causes the crash also with heavy tracks and any engine.

[jamespetts]

Hmm - after much tinkering, I still can't reproduce this one. Are you using a 32-bit or 64-bit platform?

[sdog]

as always, 64 bit linux binaries, compiled with 4.4.3 gcc.

[sdog]

here's a savegame where the crash is 'primed'.
Train 841 an EMU is stuck before a newly built tunnel, if you delete it (or fix the third rail) a following steam train drives into the tunnel and crashes the game.

http://dl.dropbox.com/u/1876190/71.sve

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x000000000044c008 in weg_t::get_max_weight (this=0x0)
   at boden/../boden/wege/weg.h:193
193 uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044c008 in weg_t::get_max_weight (this=0x0)
   at boden/../boden/wege/weg.h:193
#1  0x000000000064e564 in waggon_t::ist_befahrbar (this=0xa034e10,
   bd=0x69adec8) at vehicle/simvehikel.cc:2933
#2  0x0000000000646a11 in vehikel_t::hop_check (this=0xa034e10)
   at vehicle/simvehikel.cc:1157
#3  0x0000000000643aef in vehikel_basis_t::fahre_basis (this=0xa034e10,
   distance=128424) at vehicle/simvehikel.cc:303
#4  0x00000000005a83d6 in convoi_t::sync_step (this=0xa033f10, delta_t=100)
   at simconvoi.cc:660
#5  0x0000000000623eff in karte_t::sync_step (this=0x1213320, delta_t=100,
   sync=true, display=false) at simworld.cc:2765
#6  0x0000000000630c42 in karte_t::interactive (this=0x1213320,
   quit_month=2147483647) at simworld.cc:5776
#7  0x00000000005e5fd7 in simu_main (argc=1, argv=0x7fffffffe2d8)
   at simmain.cc:1076
#8  0x000000000066ae76 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749


the savegame requires latest development version of pak128 britain experimental and devel branch of experimental. simversion.h version numbers were stepped up to 9. But this should probably not interfere with your testing.

[jamespetts]

SDog,

it does mean that I cannot load the saved game until I step up the numbers myself, which may not be for some time. There may also be  (and, indeed, probably will be) further changes to the saved game format between now and the time that I do so, making your saved game incompatible with all released versions.

[sdog]

ciao james,

last time i checked the savegame could be loaded without stepping up the number. Some of the new features won't work however, which shouldn't change a lot for the crash. Besides stepping up the version in simversin.h and compiling it takes roughly a minute. let git restore the old version of the file afterwards.

sdog

ps.: just thought about the old version number again: the train causing the crash is reversing on his schedule. perhaps starting without the reverse schedule patches active could mean it doesn't find it's way to the 'crash-site'. (you should perhaps think about stepping up the version numbers in dev versions anyway. else you will always hide possible bugs from testing. only to be found when you step up the number for release.)

[sdog]

An old friend is back, or rather never really was away.

Program received signal SIGSEGV, Segmentation fault.
0x000000000044d7c2 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:192
192      uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044d7c2 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:192
#1  0x000000000066d0ee in waggon_t::ist_befahrbar (this=0x7fffe33ede60,
    bd=0x7fffe1ca6dc8) at vehicle/simvehikel.cc:2917
#2  0x00000000006657a3 in vehikel_t::hop_check (this=0x7fffe33ede60)
    at vehicle/simvehikel.cc:1161
#3  0x0000000000662813 in vehikel_basis_t::fahre_basis (this=0x7fffe33ede60,
    distance=36238) at vehicle/simvehikel.cc:306
#4  0x00000000005bfdd4 in convoi_t::sync_step (this=0x7fffe33ed7c0, delta_t=34)
    at simconvoi.cc:731
#5  0x00000000006411ed in karte_t::sync_step (this=0x7fffea7144a0, delta_t=34,
    sync=true, display=true) at simworld.cc:2827
#6  0x00000000005f7b8a in interrupt_check (
    caller_info=0x6bf800 "karte_t::interactive()") at simintr.cc:101
#7  0x000000000064e708 in karte_t::interactive (this=0x7fffea7144a0,
    quit_month=2147483647) at simworld.cc:5981
#8  0x00000000006003c4 in simu_main (argc=1, argv=0x7fffffffe2e8)
    at simmain.cc:1141

A train was runing on a normal track, after it leaft station A i paused the game, removed a length of track shortly before station B. Built elevated track and connected the ends with two bridge segments (Fig. 1). On it's way to station B the train was moving on this piece of track and triggered the segfault (see bt above and Fig. 2)

I can reproduce the crash consistently. There are some factors however that can prevent it.
- Route new calculation (loading, opening schedule.)
- the train is very close to the place that gets replaced. The signal in front of it is already switched green/pass.

Tested with latest simutrans-experimental 9.x branch from james' github (after commit 7 november). Pakbritain-ex master branch of same date. Compiled and run in 64 bit ubuntu, gcc 4.4.3


Fig 1: Before crashing, the train is more than one signaling section away, the elevated way is placed but not connected.


Fig 2: Last rendered screen at the crash. The proximity of the second train was not important for triggering the crash.

[Carl]

I've come across something similar to this. If a train has already calculated a route from A to B, and I delete part of this route and replace it with an elevated track, a crash sometimes happens when the train recalculates its route. This only happens when elevated track is involved in the rebuilding of the track.

[jamespetts]

I'm afraid that I can't reproduce this in 9.x replacing straight track with elevated track - the game carries on as normal with no crash.

[sdog]

Code Select Expand



#0  0x000000000044d810 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:192
#1  0x0000000000672fa2 in waggon_t::ist_befahrbar (this=0xd40f250, bd=0x7131dc8)
    at vehicle/simvehikel.cc:2917
#2  0x000000000066b65f in vehikel_t::hop_check (this=0xd40f250)
    at vehicle/simvehikel.cc:1161
#3  0x00000000006686cf in vehikel_basis_t::fahre_basis (this=0xd40f250,
    distance=114435) at vehicle/simvehikel.cc:306
#4  0x00000000005c52b6 in convoi_t::sync_step (this=0xd40df80, delta_t=100)
    at simconvoi.cc:754
#5  0x0000000000646935 in karte_t::sync_step (this=0x15233c0, delta_t=100,
    sync=true, display=false) at simworld.cc:2841
#6  0x0000000000654925 in karte_t::interactive (this=0x15233c0,
    quit_month=2147483647) at simworld.cc:6133
#7  0x0000000000605529 in simu_main (argc=1, argv=0x7fffffffe268)
    at simmain.cc:1181
#8  0x00000000006906e7 in main (argc=1, argv=0x7fffffffe268) at simsys_s.cc:770

this time i got a savegame that reproduces the crash for me repeatedly.
147.sve

[jamespetts]

Thank you for uploading that: when I get a moment, I shall investigate. Are there any particular steps necessary to reproduce? And what version did you use; is this from the latest 9.x branch, or an earlier pull?

[sdog]

It was tested with 9.x before you patched in inkleyad's 'line spacing' (commit  51e8141c6c5b517177f2). Sorry for not telling, it was late already . I hope you still have kept the binaries, since the savegame shouldn't be compatible with the newest 9.x anymore.

You don't have to do anything, the train is shortly before the station and will crash when going up the elevated track, the view is centred on.

I have a hunch this might even run for you, at least from our previous discussion. Don't forget i'm testing on a 64 bit linux.

[jamespetts]

Aha - finally I get the crash! I have now found the problem (which was a simple error: a failure to check whether a value was NULL or not), and it will be fixed in the next release. Thank you very much for chasing this one down so tirelessly.

[sdog]

i'm quite happy to hear you could track down this one. good job james!