[Fixed] New crash in -devel, reproducable

Topic: [Fixed] New crash in -devel, reproducable (Read 7164 times) previous topic - next topic

[Fixed] New crash in -devel, reproducable

April 27, 2010, 01:07:32 am

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)

Re: New crash in -devel, reproducable

Reply #1 – April 27, 2010, 01:22:43 am

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

Re: New crash in -devel, reproducable

Reply #2 – April 27, 2010, 01:29:40 am

Quote from: jamespetts – on April 27, 2010, 01:22:43 am

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]

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]

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]

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....

Re: New crash in -devel, reproducable

Reply #3 – April 27, 2010, 09:05:34 am

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.

Re: New crash in -devel, reproducable

Reply #4 – April 27, 2010, 09:36:50 am

Quote from: jamespetts – on April 27, 2010, 09:05:34 am

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

Re: New crash in -devel, reproducable

Reply #5 – April 27, 2010, 09:56:20 am

Quote from: neroden – on April 27, 2010, 09:36:50 am

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.

Re: New crash in -devel, reproducable

Reply #6 – April 27, 2010, 11:31:43 am

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 cl**** 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]

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?

Re: New crash in -devel, reproducable

Reply #7 – April 29, 2010, 01:23:20 am

Appears to be fixed in cb60d749c1846f9585170e376e06a699c37f71fc

This is the danger of not checking array bounds. The compiler has the right to ****ume 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.

Re: New crash in -devel, reproducable

Reply #8 – April 29, 2010, 09:31:40 am

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