[Fixed] New crash in -devel, reproducable

[neroden]

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
fabrik_t::recalc_factory_status (this=0xeba3b28) at simfab.cc:1465
1465 int haltcount=welt->lookup(pos.get_2d())->get_haltlist_count();
(gdb) bt
#0  fabrik_t::recalc_factory_status (this=0xeba3b28) at simfab.cc:1465
#1  0x081f4a40 in fabrik_t::step (this=0xeba3b28, delta_t=263)
   at simfab.cc:1091
#2  0x0826ea88 in karte_t::step (this=0xd07fd30) at simworld.cc:3396
#3  0x0826f48b in karte_t::interactive (this=0xd07fd30, quit_month=2147483647)
   at simworld.cc:5737
#4  0x0821b107 in simu_main (argc=1, argv=0xbffff434) at simmain.cc:1069
#5  0x082a9d2a in main (argc=1, argv=0xbffff434) at simsys_s.cc:743


This is in a brand new game, after a short period of time (perhaps the first factory production increment; it's also just after I started the first factory-to-factory convoy running)

[jamespetts]

Hmm, I can't reproduce this one. Can you send me/post a saved game?

[neroden]

Hmm, I can't reproduce this one. Can you send me/post a saved game?

Sure, but I doubt it will help... given the nature of the crash, which is happening with brand new games.  This looks like another compiler-specific crash :-(

EDIT: an alternative crash, this time before building any convoys:

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x081f4aab in fabrik_t::step (this=0xef3b3f1, delta_t=247) at simfab.cc:969
969 if(!besch->is_electricity_producer()) {
(gdb) bt
#0  0x081f4aab in fabrik_t::step (this=0xef3b3f1, delta_t=247) at simfab.cc:969
#1  0x0826ea88 in karte_t::step (this=0xd01f0d8) at simworld.cc:3396
#2  0x0826f48b in karte_t::interactive (this=0xd01f0d8, quit_month=2147483647)
   at simworld.cc:5737
#3  0x0821b107 in simu_main (argc=1, argv=0xbffff434) at simmain.cc:1069
#4  0x082a9d2a in main (argc=1, argv=0xbffff434) at simsys_s.cc:743


Another variant.  All I need to do is build some plateway and then hit fast-forward.  The plateway may not even be necessary.

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
fabrik_t::step (this=0xf44f508, delta_t=100) at simfab.cc:1042
1042 const uint32 pb = besch->get_produkt(produkt)->get_faktor();
(gdb) bt
#0  fabrik_t::step (this=0xf44f508, delta_t=100) at simfab.cc:1042
#1  0x0826ea88 in karte_t::step (this=0xd01f320) at simworld.cc:3396
#2  0x0826f79a in karte_t::interactive (this=0xd01f320, quit_month=2147483647)
   at simworld.cc:5702
#3  0x0821b107 in simu_main (argc=1, argv=0xbffff434) at simmain.cc:1069
#4  0x082a9d2a in main (argc=1, argv=0xbffff434) at simsys_s.cc:743


I think "besch" may be an invalid pointer?

EDIT: Very interesting.  I got a different crash this time:

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x081b65d3 in stadt_t::calc_growth() ()
(gdb) bt
#0  0x081b65d3 in stadt_t::calc_growth() ()
#1  0x081ca1c8 in stadt_t::step(long) ()
#2  0x0826ea32 in karte_t::step (this=0xe227930) at simworld.cc:3387
#3  0x0826f79a in karte_t::interactive (this=0xe227930, quit_month=2147483647) at simworld.cc:5702
#4  0x0821b107 in simu_main (argc=1, argv=0xbffff434) at simmain.cc:1069
#5  0x082a9d2a in main (argc=1, argv=0xbffff434) at simsys_s.cc:743


There's something more fundamental going on here....

[jamespetts]

I'm not getting any of those, I'm afraid. Which version of GCC are you using...? And with which commit did the crashes start...?

Edit: It does look to me as though a whole set of pointers are getting corrupted somewhere, but I'm not sure that I can think where. I double checked all the calls to the new union that I made recently, and those are all safe now, and I'm not sure why you're getting them and I'm not. Do you have optimisations enabled? I turn them off for debug builds. If you do, try turning them off and seeing whether you still get a crash.

[neroden]

I'm not getting any of those, I'm afraid. Which version of GCC are you using...? And with which commit did the crashes start...?

Edit: It does look to me as though a whole set of pointers are getting corrupted somewhere, but I'm not sure that I can think where. I double checked all the calls to the new union that I made recently, and those are all safe now, and I'm not sure why you're getting them and I'm not. Do you have optimisations enabled? I turn them off for debug builds. If you do, try turning them off and seeing whether you still get a crash.

I'll do that.  But first I'm bisecting the tree to figure out *exactly* which commit induced the crash... it's clearly a very recent one, as my branch works just after the very complicated merge from standard.

Edit: I wouldn't be entirely surprised if this turned out to be related to your mysterious performance slowdown (which I'm *not* getting).

Edit: This is the killer commit (so unrelated to the performance issue)):
fcdf6e25ac765915bcf993f6c5717858adb03a9b

[jamespetts]

Edit: I wouldn't be entirely surprised if this turned out to be related to your mysterious performance slowdown (which I'm *not* getting).

Hmm - I didn't think that it was that mysterious, given the number of calls to route_t::find_route. However, if I'm getting it and you're not on the same maps with similar system specifications and the same level of build optimisation, then perhaps it should raise eyebrows. Thank you for looking into this, and sorry that you've had trouble.

[neroden]

Just crossed messages....
anyway, I found the problem commit, noted above.

I'm betting your performance problem is due to function call overhead which is optimized out by inlining when optimization is turned on.  Have you tried an optimized build?  (If this works, force inlining by putting appropriate functions into class declarations.)

EDIT: Yes, it still happens at -O0.  This was, mind you, tested on the *first* revision to show the crash.  Today's crash:

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x0806d4b7 in grund_t::ist_tunnel (this=0x0) at bauer/../boden/grund.h:326
326 return ( (get_typ()==tunnelboden) );
(gdb) bt
#0  0x0806d4b7 in grund_t::ist_tunnel (this=0x0) at bauer/../boden/grund.h:326
#1  0x080b4a72 in gebaeude_t::calc_bild (this=0xe5acd50)
    at dings/gebaeude.cc:373
#2  0x080594ca in gebaeude_t::check_season (this=0xe5acd50)
    at bauer/../besch/../dings/gebaeude.h:127
#3  0x080933b2 in dingliste_t::check_season (this=0xe51925c, month=21602)
    at dataobj/dingliste.cc:1235
#4  0x081f9528 in grund_t::check_season (this=0xe519258, month=21602)
    at boden/grund.h:241
#5  0x081f82b9 in planquadrat_t::check_season (this=0xe497724, month=21602)
    at simplan.cc:301
#6  0x082277c5 in karte_t::step (this=0xe210930) at simworld.cc:3352
#7  0x08230bd6 in karte_t::interactive (this=0xe210930, quit_month=2147483647)
    at simworld.cc:5702
#8  0x081ed35d in simu_main (argc=1, argv=0xbffff434) at simmain.cc:1068
#9  0x08263e9b in main (argc=1, argv=0xbffff434) at simsys_s.cc:743


Perhaps this backtrace is a little more helpful than the others.  Especially since we now know which commit is at fault.  Got any clues yet?

[neroden]

Appears to be fixed in cb60d749c1846f9585170e376e06a699c37f71fc

This is the danger of not checking array bounds.  The compiler has the right to assume that the array bounds aren't overflowed, so out-of-bounds array accesses in the source code can cause arbitrarily bizarre memory corruption, even in places which appear totally unrelated.  Anyway, with the correct array access, it seems to work. 

[jamespetts]

Glad that it's fixed! Thank you for testing.