[crash devel] crash when starting/loading demo.sve

[sdog]

the latest devel version 2010-07-24 crashes when loading demo.sve of pak128.britain.

Code:

FATAL ERROR: loadsave_t::rdwr_str()
string longer (511) than allowed size (2)


Program received signal SIGABRT, Aborted.
0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c225c0 in abort () from /lib/libc.so.6
#2  0x000000000063febe in log_t::fatal (this=0xa7d390,
    who=0x678ddb "loadsave_t::rdwr_str()",
    format=0x678ed8 "string longer (%i) than allowed size (%i)")
    at utils/log.cc:242
#3  0x0000000000467648 in loadsave_t::rdwr_str (this=0x7fffffffbbb0,
    s=0x7fffffffb1f0 "~", size=2) at dataobj/loadsave.cc:732
#4  0x000000000048704e in leitung_t::rdwr (this=0x7fffea880730,
    file=0x7fffffffbbb0) at dings/leitung2.cc:447
#5  0x000000000048720d in pumpe_t (this=0x7fffea880730, welt=0x7fffea58d480,
    file=0x7fffffffbbb0) at dings/leitung2.cc:476
#6  0x0000000000456893 in dingliste_t::rdwr (this=0x7fffea873490,
    welt=0x7fffea58d480, file=0x7fffffffbbb0, current_pos=...)
    at dataobj/dingliste.cc:762
#7  0x0000000000446318 in grund_t::rdwr (this=0x7fffea873488,
    file=0x7fffffffbbb0) at boden/grund.cc:367
#8  0x00000000005f7279 in boden_t (this=0x7fffea873488, welt=0x7fffea58d480,
    file=0x7fffffffbbb0, pos=...) at boden/boden.h:27
#9  0x00000000005f5b6b in planquadrat_t::rdwr (this=0x7fffea5d9f18,
    welt=0x7fffea58d480, file=0x7fffffffbbb0, pos=...) at simplan.cc:249
#10 0x000000000062ee0e in karte_t::laden (this=0x7fffea58d480,
    file=0x7fffffffbbb0) at simworld.cc:4549
#11 0x000000000062de04 in karte_t::laden (this=0x7fffea58d480,
    filename=0x7fffe8882ad8 "/home/gschenk/simuexp/pak128.britain-ex/demo.sve")
    at simworld.cc:4346
#12 0x00000000005e8592 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:867
#13 0x000000000066e916 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

without demo.sve it still crashes: <== resolved

Code:

Program received signal SIGSEGV, Segmentation fault.
0x000000000042d29c in karte_t::ist_in_gittergrenzen (this=0x0, x=1, y=1)
    at bauer/../simworld.h:813
813 return (x|y|(cached_groesse_gitter_x-x)|(cached_groesse_gitter_y-y))>=0;
(gdb) bt
#0  0x000000000042d29c in karte_t::ist_in_gittergrenzen (this=0x0, x=1, y=1)
    at bauer/../simworld.h:813
#1  0x000000000042d374 in karte_t::lookup_hgt (this=0x0, k=...)
    at bauer/../simworld.h:1057
#2  0x000000000059fb76 in stadt_t::random_place (wl=0x42662f0,
    sizes_list=0x4134ad0, old_x=0, old_y=0) at simcity.cc:4295
#3  0x000000000061d3d9 in karte_t::distribute_groundobjs_cities (
    this=0x42662f0, sets=0x42636b0, old_x=0, old_y=0) at simworld.cc:857
#4  0x0000000000620ee6 in karte_t::enlarge_map (this=0x42662f0,
    sets=0x42636b0, h_field=0x0) at simworld.cc:1558
#5  0x000000000061f5b9 in karte_t::init (this=0x42662f0, sets=0x7fffffffc730,
    h_field=0x0) at simworld.cc:1270
#6  0x00000000005e8724 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:888
#7  0x000000000066e916 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

tested on linux 64 with gcc 4.4.3


there were several changes in loadsave calls in the merge from standard. e.g.:

Code:

-senke_t::senke_t(karte_t *welt, loadsave_t *file) : leitung_t(welt , file)
  577
+senke_t::senke_t(karte_t *welt, loadsave_t *file) : leitung_t( welt, koord3d::invalid, NULL )

maybe they're to blame for the first crash?

[jamespetts]

Whenever the rdwr function of einstellugen.cc changes, you will need to delete settings-experimental-devel.xml before starting the game. On this occasion, this is brought about by a change from Standard, in which the settings from forestrules.tab are merged with simuconf.tab.

[sdog]

oh, i deleted the .xml, i will check again.
no *.xml files in my simutrans dir.

is a new simuconf.tab required to run it?

[jamespetts]

If you deleted the right .xml file, then I can't reproduce this crash. A bad simuconf.tab file should not cause a crash.

[sdog]

sorry can't really concentrate on this, and right now i'm in a rather unreliable state. checked again that all xml are deleted. also the crash with a wrong xml happens earlier, when i remember correctly. but if vou can't reproduce it, don't worry about it until i've checked everything again when i have a clear head again.

[jamespetts]

Although this doesn't affect the standard demo.sve that comes with Pak128.Britain-Ex 0.6, I have pushed a change to Github this morning that deals with a problem with loading some older saved games: do let me know whether this fixes the problem.

[inkelyad]

without demo.sve it still crashes:

Looks like my error.
Fix pushed to my github devel branch. link

[sdog]

With james latest devel version the crash when creating a new demo map does not occur anymore. I haven't seen that your fix was included already inkelyad, so it must have been something else.


The games still crashes at startup when loading demo.sve

Code:

Program received signal SIGABRT, Aborted.
0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c225c0 in abort () from /lib/libc.so.6
#2  0x000000000063f26e in log_t::fatal (this=0xa7b390,
    who=0x67807b "loadsave_t::rdwr_str()",
    format=0x678178 "string longer (%i) than allowed size (%i)")
    at utils/log.cc:242
#3  0x00000000004670f4 in loadsave_t::rdwr_str (this=0x7fffffffbbb0,
    s=0x7fffffffb1f0 "~", size=2) at dataobj/loadsave.cc:731
#4  0x00000000004869d0 in leitung_t::rdwr (this=0x3f6e3b0, file=0x7fffffffbbb0)
    at dings/leitung2.cc:447
#5  0x0000000000486b8f in pumpe_t (this=0x3f6e3b0, welt=0x11f8830,
    file=0x7fffffffbbb0) at dings/leitung2.cc:476
#6  0x00000000004567e2 in dingliste_t::rdwr (this=0x4626d90, welt=0x11f8830,
    file=0x7fffffffbbb0, current_pos=...) at dataobj/dingliste.cc:762
#7  0x00000000004462a6 in grund_t::rdwr (this=0x4626d88, file=0x7fffffffbbb0)
    at boden/grund.cc:367
#8  0x00000000005f665d in boden_t (this=0x4626d88, welt=0x11f8830,
    file=0x7fffffffbbb0, pos=...) at boden/boden.h:27
#9  0x00000000005f4f4f in planquadrat_t::rdwr (this=0x43a1288, welt=0x11f8830,
    file=0x7fffffffbbb0, pos=...) at simplan.cc:249
#10 0x000000000062e294 in karte_t::laden (this=0x11f8830, file=0x7fffffffbbb0)
---Type <return> to continue, or q <return> to quit---
    at simworld.cc:4550
#11 0x000000000062d296 in karte_t::laden (this=0x11f8830,
    filename=0x2524368 "/home/gschenk/simuexp/pak128.britain-ex/demo.sve")
    at simworld.cc:4347
#12 0x00000000005e79e2 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:867
#13 0x000000000066dbb2 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

when loading my own savegame, saved directly before this latest version i get this crash:

Code:

FATAL ERROR: planquadrat_t::rdwr()
Error while loading game: Unknown ground type '0'


Program received signal SIGABRT, Aborted.
0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c225c0 in abort () from /lib/libc.so.6
#2  0x000000000063f26e in log_t::fatal (this=0xa7b390,
    who=0x69b2a3 "planquadrat_t::rdwr()",
    format=0x69b270 "Error while loading game: Unknown ground type '%d'")
    at utils/log.cc:242
#3  0x00000000005f5123 in planquadrat_t::rdwr (this=0x7fffecd70018,
    welt=0x14f4d50, file=0x7fffffffb1e0, pos=...) at simplan.cc:257
#4  0x000000000062e294 in karte_t::laden (this=0x14f4d50, file=0x7fffffffb1e0)
    at simworld.cc:4550
#5  0x000000000062d296 in karte_t::laden (this=0x14f4d50,
    filename=0x4b3b6d8 "\221\001\375\001") at simworld.cc:4347
#6  0x000000000051c655 in loadsave_frame_t::action (this=0x4b71ba0,
    filename=0x4b3b6d8 "\221\001\375\001") at gui/loadsave_frame.cc:51
#7  0x000000000053e480 in savegame_frame_t::action_triggered (this=0x4b71ba0,
    komp=0x4b721a8, p=...) at gui/savegame_frame.cc:399
#8  0x00000000004ac99b in gui_action_creator_t::call_listeners (
    this=0x4b721a8, v=...) at gui/components/gui_action_creator.h:36
#9  0x00000000004c847e in gui_table_t::infowin_event (this=0x4b72190,
    ev=0x7fffffffb840) at gui/components/gui_table.cc:146
#10 0x00000000004c4ef0 in gui_scrollpane_t::infowin_event (this=0x4b72390,
    ev=0x7fffffffb8a0) at gui/components/gui_scrollpane.cc:102
#11 0x0000000000500c73 in gui_container_t::infowin_event (this=0x4b71ba8,
    ev=0x7fffffffb980) at gui/gui_container.cc:171
#12 0x0000000000502773 in gui_frame_t::infowin_event (this=0x4b71ba0,
    ev=0x7fffffffba30) at gui/gui_frame.cc:88
#13 0x000000000053f13f in savegame_frame_t::infowin_event (this=0x4b71ba0,
    ev=0x7fffffffba30) at gui/savegame_frame.cc:545
#14 0x0000000000617fe3 in check_pos_win (ev=0x7fffffffbb60) at simwin.cc:984
#15 0x0000000000632f80 in karte_t::interactive (this=0x14f4d50,
    quit_month=2147483647) at simworld.cc:5680
#16 0x00000000005e8684 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:1067
#17 0x000000000066dbb2 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

This error is an old aquaintance. The savegame was saved with experimental version set to 9.0. Loading and saving worked without any apparent flaws before. I tested with the latest master branch of pak128.britain-experimental.

[inkelyad]

I haven't seen that your fix was included already inkelyad, so it must have been something else.

It can be unrelated, but it was NULL dereference.

Code:

#1  0x000000000042d374 in karte_t::lookup_hgt (this=0x0, k=...)

See. this == 0x0

[jamespetts]

SDog,

if you set the version to 9.0 before the official 9.x branch is created, then this problem is likely to arise because the save game format will be changed between different commits, so loading a game saved with one commit using a version compiled from another commit will generate an error. If, however, you have saved a game then try to re-load it using exactly the same binary and it fails, then there is a problem that needs to be addressed. Could you confirm whether or not that is the case? Thank you for your report.

[prissi]

If, for development, xml_zipped is used as standard savegame format, such errors would be detected very easily, sinc ethen header and footer would not match.

[sdog]

If, however, you have saved a game then try to re-load it using exactly the same binary and it fails, then there is a problem that needs to be addressed. Could you confirm whether or not that is the case? Thank you for your report.

it worked of course, i would have reported it as a bug if it hadn't.

james, it's not necessary to make yourself the work of always explaining trivial reasons for crashes. just ignore the unimportant part. else i always get the feeling to bother you when i report trivial bugs/crashes. not reporting them however would not a good approach either, since i would else apply judgement.

[inkelyad]

Looking at commit 8af544384fcdfa1d9adb9e69638c097fb9aa4cf2 by jamespetts.

Looks like my error.
Fix pushed to my github devel branch

It was too haste and wrong 'fix'. Correct (i hope) variant pushed to github.

[jamespetts]

Thank you very much!