[Valgrind v5.0]

Topic: [Valgrind v5.0] (Read 15196 times) previous topic - next topic

[Valgrind v5.0]

July 15, 2009, 08:41:37 pm

Hi,

I run SimutranExperimental built from today sources ( 2009VII15 ) with Valgrind tool. It was a new short game, only one tram line and one bus line created and run by about month.
Valgrind showed usage of some unitialized variables and memory leaks. I think it can be useful for developers , so I attach valgrind log from this game. Even if some problems reported are minors and hasn't bit influence on game, I think it can be worth of clean it up as later it will be easier to catch serious problems.
I'll try later run valgrind with larger p****enger network but first I have to create one

Re: [Valgrind v5.0]

Reply #1 – July 15, 2009, 08:49:26 pm

Hanczar,

welcome to the forums, and thank you very much indeed for your contribution - it is very much appreciated :-) I shall have to look through that log carefully and see what I can fix. I should be very grateful if you could run Valgrind again on version 5.1 when I release it. Thank you very much :-)

Edit: I have had a brief look, and it seems that most of the errors are contained in code that is unmodified from Simutrans-Standard...

Re: [Valgrind v5.0]

Reply #2 – July 15, 2009, 09:31:08 pm

Hi Hanczar

Thank you very much for your great help!!

May I know whether you were using centralised path searching system or distributed path searching system during testing?

I can't find any entry in your file regarding path_explorer_t or path_explorer.cc . I just want to make sure.

Many thanks once again!

Knightly

Re: [Valgrind v5.0]

Reply #3 – July 15, 2009, 09:47:19 pm

step_p****agiere was clean the last time I did valgrind, same for depot. Thus I suppose they are either new or from experimental.

Re: [Valgrind v5.0]

Reply #4 – July 15, 2009, 11:21:15 pm

Quote

I should be very grateful if you could run Valgrind again on version 5.1

No problem

As soon as it'll be available

Quote

May I know whether you were using centralised path searching system or distributed path searching system during testing?

I can't find any entry in your file regarding path_explorer_t or path_explorer.cc . I just want to make sure.

Centralised. So problems in path_explorer not detected yet

I run it again with same larger game and there seems to be one problem which occurs in hundreds times

Conditional jump or move depends on uninitialised value(s)
==16003== at 0x81E0D13: money_to_string(char*, double) (simstring.cc:82)
==16003== Uninitialised value was created by a heap allocation
==16003== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==16003== by 0x817B94D: convoi_t::rdwr(loadsave_t*) (simconvoi.cc:2178)
==16003== by 0x817F031: convoi_t::convoi_t(karte_t*, loadsave_t*) (simconvoi.cc:190)
==16003== by 0x81D36E7: karte_t::laden(loadsave_t*) (simworld.cc:3969)
==16003== by 0x51E58803:

Something is not initialized during load?
whole log attached

Re: [Valgrind v5.0]

Reply #5 – July 16, 2009, 07:40:01 am

I have fixed some unitialized variables in standard simutrans, for instance

Quote

karte_t::distribute_groundobjs_cities(int, short, short) (simworld.cc:1055)
vehikel_basis_t::get_screen_offset(int&, int&) const (simvehikel.cc:360)

and something related to loading of powerlines.

However, using the depot-window and buying a new convoi yields no valgrind errors for me. I suspect they are due to the vehicle-replace patch integrated in st-experimental.

Re: [Valgrind v5.0]

Reply #6 – July 16, 2009, 08:00:31 am

Quote from: prissi – on July 15, 2009, 09:47:19 pm

step_p****agiere was clean the last time I did valgrind, same for depot. Thus I suppose they are either new or from experimental.

Maybe Valgrind check can be done again on Simutrans Standard? The helps to isolate the source of the problems (Simutrans Standard code or Simutrans Experimental code).

Re: [Valgrind v5.0]

Reply #7 – July 16, 2009, 10:39:03 am

here is a valgrind report on simutrans standard. I ran a pak128 a couple of minute. The only "Conditional jump or move depends on uninitialised value(s)" appears around some SDL and system calls.

Code: [Select]

==8491== Memcheck, a memory error detector.
==8491== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==8491== Using LibVEX rev 1732, a library for dynamic binary translation.
==8491== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==8491== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==8491== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==8491== For more details, rerun with: -v
==8491== 
==8491== My PID = 8491, parent PID = 2124.  Prog and args are:
==8491==    ./sim
==8491== 
==8491== Conditional jump or move depends on uninitialised value(s)
==8491==    at 0x60107C7: shm_sum_discard (pcm_dmix.c:121)
==8491==    by 0x6011776: snd_pcm_dmix_close (pcm_dmix.c:652)
==8491==    by 0x5FE5C44: snd_pcm_close (pcm.c:707)
==8491==    by 0x601A167: softvol_free (pcm_softvol.c:373)
==8491==    by 0x601A17F: snd_pcm_softvol_close (pcm_softvol.c:384)
==8491==    by 0x5FE5C44: snd_pcm_close (pcm.c:707)
==8491==    by 0x5FFE4EC: snd_pcm_plug_close (pcm_plug.c:71)
==8491==    by 0x5FE5C44: snd_pcm_close (pcm.c:707)
==8491==    by 0x50736E8: (within /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x5047FBE: SDL_AudioInit (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x50473FC: SDL_InitSubSystem (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x5EC04C: dr_init_sound() (sdl_sound.cc:111)
==8491== 
==8491== Conditional jump or move depends on uninitialised value(s)
==8491==    at 0x6016A6A: snd_pcm_direct_shm_create_or_connect (pcm_direct.c:120)
==8491==    by 0x60119F2: snd_pcm_dmix_open (pcm_dmix.c:844)
==8491==    by 0x6012388: _snd_pcm_dmix_open (pcm_dmix.c:1163)
==8491==    by 0x5FE4877: snd_pcm_open_conf (pcm.c:2114)
==8491==    by 0x5FE4EC6: snd_pcm_open_noupdate (pcm.c:2152)
==8491==    by 0x5FE4F39: snd_pcm_open_slave (pcm.c:2238)
==8491==    by 0x601ABE3: _snd_pcm_softvol_open (pcm_softvol.c:984)
==8491==    by 0x5FE4877: snd_pcm_open_conf (pcm.c:2114)
==8491==    by 0x5FE4F76: snd_pcm_open_slave (pcm.c:2240)
==8491==    by 0x5FFE171: _snd_pcm_plug_open (pcm_plug.c:1225)
==8491==    by 0x5FE4877: snd_pcm_open_conf (pcm.c:2114)
==8491==    by 0x5FE4F76: snd_pcm_open_slave (pcm.c:2240)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x42C163: wegbauer_t::intern_calc_route(vector_tpl<koord3d> const&, vector_tpl<koord3d> const&) (wegbauer.cc:994)
==8491==    by 0x42CDFA: wegbauer_t::calc_route(vector_tpl<koord3d> const&, vector_tpl<koord3d> const&) (wegbauer.cc:1528)
==8491==    by 0x42CFE9: wegbauer_t::calc_route(koord3d const&, koord3d const&) (wegbauer.cc:1504)
==8491==    by 0x5B3D93: karte_t::create_rivers(short) (simworld.cc:817)
==8491==    by 0x5B3F95: karte_t::distribute_groundobjs_cities(int, short, short) (simworld.cc:840)
==8491==    by 0x5BB0CB: karte_t::enlarge_map(einstellungen_t*, signed char*) (simworld.cc:1464)
==8491==    by 0x5BB88C: karte_t::init(einstellungen_t*, signed char*) (simworld.cc:1211)
==8491==    by 0x582125: simu_main(int, char**) (simmain.cc:782)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491==  Address 0xB9BE170 is 0 bytes inside a block of size 5 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x411665: vector_tpl<koord3d>::vector_tpl(unsigned) (vector_tpl.h:26)
==8491==    by 0x42CFB0: wegbauer_t::calc_route(koord3d const&, koord3d const&) (wegbauer.cc:1501)
==8491==    by 0x5B3D93: karte_t::create_rivers(short) (simworld.cc:817)
==8491==    by 0x5B3F95: karte_t::distribute_groundobjs_cities(int, short, short) (simworld.cc:840)
==8491==    by 0x5BB0CB: karte_t::enlarge_map(einstellungen_t*, signed char*) (simworld.cc:1464)
==8491==    by 0x5BB88C: karte_t::init(einstellungen_t*, signed char*) (simworld.cc:1211)
==8491==    by 0x582125: simu_main(int, char**) (simmain.cc:782)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x42C31E: wegbauer_t::intern_calc_route(vector_tpl<koord3d> const&, vector_tpl<koord3d> const&) (wegbauer.cc:1040)
==8491==    by 0x42CDFA: wegbauer_t::calc_route(vector_tpl<koord3d> const&, vector_tpl<koord3d> const&) (wegbauer.cc:1528)
==8491==    by 0x42CFE9: wegbauer_t::calc_route(koord3d const&, koord3d const&) (wegbauer.cc:1504)
==8491==    by 0x5B3D93: karte_t::create_rivers(short) (simworld.cc:817)
==8491==    by 0x5B3F95: karte_t::distribute_groundobjs_cities(int, short, short) (simworld.cc:840)
==8491==    by 0x5BB0CB: karte_t::enlarge_map(einstellungen_t*, signed char*) (simworld.cc:1464)
==8491==    by 0x5BB88C: karte_t::init(einstellungen_t*, signed char*) (simworld.cc:1211)
==8491==    by 0x582125: simu_main(int, char**) (simmain.cc:782)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491==  Address 0xBB35240 is 0 bytes inside a block of size 5 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x411665: vector_tpl<koord3d>::vector_tpl(unsigned) (vector_tpl.h:26)
==8491==    by 0x42CFBE: wegbauer_t::calc_route(koord3d const&, koord3d const&) (wegbauer.cc:1501)
==8491==    by 0x5B3D93: karte_t::create_rivers(short) (simworld.cc:817)
==8491==    by 0x5B3F95: karte_t::distribute_groundobjs_cities(int, short, short) (simworld.cc:840)
==8491==    by 0x5BB0CB: karte_t::enlarge_map(einstellungen_t*, signed char*) (simworld.cc:1464)
==8491==    by 0x5BB88C: karte_t::init(einstellungen_t*, signed char*) (simworld.cc:1211)
==8491==    by 0x582125: simu_main(int, char**) (simmain.cc:782)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x57C0EC: simline_t::register_stops(schedule_t*) (simline.cc:186)
==8491==    by 0x57C238: simline_t::add_convoy(quickstone_tpl<convoi_t>) (simline.cc:73)
==8491==    by 0x55FE90: convoi_t::laden_abschliessen() (simconvoi.cc:285)
==8491==    by 0x5B8513: karte_t::laden(loadsave_t*) (simworld.cc:3851)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491==    by 0x4A454C: gui_scrollpane_t::infowin_event(event_t const*) (gui_scrollpane.cc:102)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491==  Address 0xF92FCE7 is 7 bytes inside a block of size 14 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x57C546: simline_t::rdwr(loadsave_t*) (simline.cc:155)
==8491==    by 0x57E5A1: simlinemgmt_t::rdwr(karte_t*, loadsave_t*, spieler_t*) (simlinemgmt.cc:166)
==8491==    by 0x543782: spieler_t::rdwr(loadsave_t*) (simplay.cc:815)
==8491==    by 0x5B80A1: karte_t::laden(loadsave_t*) (simworld.cc:3800)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x57C0EC: simline_t::register_stops(schedule_t*) (simline.cc:186)
==8491==    by 0x57C1F7: simline_t::laden_abschliessen() (simline.cc:176)
==8491==    by 0x57D83F: simlinemgmt_t::laden_abschliessen() (simlinemgmt.cc:194)
==8491==    by 0x541EF7: spieler_t::laden_abschliessen() (simplay.cc:826)
==8491==    by 0x5B86A5: karte_t::laden(loadsave_t*) (simworld.cc:3875)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491==    by 0x4A454C: gui_scrollpane_t::infowin_event(event_t const*) (gui_scrollpane.cc:102)
==8491==  Address 0xF92F0DF is 7 bytes inside a block of size 14 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x57C546: simline_t::rdwr(loadsave_t*) (simline.cc:155)
==8491==    by 0x57E5A1: simlinemgmt_t::rdwr(karte_t*, loadsave_t*, spieler_t*) (simlinemgmt.cc:166)
==8491==    by 0x543782: spieler_t::rdwr(loadsave_t*) (simplay.cc:815)
==8491==    by 0x5B80A1: karte_t::laden(loadsave_t*) (simworld.cc:3800)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x579092: haltestelle_t::hat_gehalten(ware_besch_t const*, schedule_t const*, spieler_t const*) (simhalt.cc:887)
==8491==    by 0x579657: haltestelle_t::rebuild_destinations() (simhalt.cc:978)
==8491==    by 0x5B88B1: karte_t::laden(loadsave_t*) (simworld.cc:3897)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491==    by 0x4A454C: gui_scrollpane_t::infowin_event(event_t const*) (gui_scrollpane.cc:102)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491==    by 0x4E073C: gui_frame_t::infowin_event(event_t const*) (gui_frame.cc:89)
==8491==  Address 0xF9388D3 is 35 bytes inside a block of size 42 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x57C546: simline_t::rdwr(loadsave_t*) (simline.cc:155)
==8491==    by 0x57E5A1: simlinemgmt_t::rdwr(karte_t*, loadsave_t*, spieler_t*) (simlinemgmt.cc:166)
==8491==    by 0x543782: spieler_t::rdwr(loadsave_t*) (simplay.cc:815)
==8491==    by 0x5B80A1: karte_t::laden(loadsave_t*) (simworld.cc:3800)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x578DF1: haltestelle_t::hole_ab(ware_besch_t const*, unsigned, schedule_t const*, spieler_t const*) (simhalt.cc:1294)
==8491==    by 0x5D67D7: vehikel_t::load_freight(quickstone_tpl<haltestelle_t>) (simvehikel.cc:721)
==8491==    by 0x5D6934: vehikel_t::beladen(koord, quickstone_tpl<haltestelle_t>) (simvehikel.cc:1330)
==8491==    by 0x556B33: convoi_t::hat_gehalten(koord, quickstone_tpl<haltestelle_t>) (simconvoi.cc:2200)
==8491==    by 0x5572E6: convoi_t::laden() (simconvoi.cc:2081)
==8491==    by 0x55BE29: convoi_t::step() (simconvoi.cc:724)
==8491==    by 0x5B1505: karte_t::step() (simworld.cc:2862)
==8491==    by 0x5B24DC: karte_t::interactive() (simworld.cc:4544)
==8491==    by 0x582B64: simu_main(int, char**) (simmain.cc:940)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491==  Address 0xF8DB8FF is 7 bytes inside a block of size 14 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x55EC46: convoi_t::rdwr(loadsave_t*) (simconvoi.cc:1711)
==8491==    by 0x561748: convoi_t::convoi_t(karte_t*, loadsave_t*) (simconvoi.cc:166)
==8491==    by 0x5B7D1D: karte_t::laden(loadsave_t*) (simworld.cc:3776)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x557249: convoi_t::laden() (simconvoi.cc:2074)
==8491==    by 0x55BE29: convoi_t::step() (simconvoi.cc:724)
==8491==    by 0x5B1505: karte_t::step() (simworld.cc:2862)
==8491==    by 0x5B24DC: karte_t::interactive() (simworld.cc:4544)
==8491==    by 0x582B64: simu_main(int, char**) (simmain.cc:940)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491==  Address 0xF8F2573 is 35 bytes inside a block of size 42 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x55EC46: convoi_t::rdwr(loadsave_t*) (simconvoi.cc:1711)
==8491==    by 0x561748: convoi_t::convoi_t(karte_t*, loadsave_t*) (simconvoi.cc:166)
==8491==    by 0x5B7D1D: karte_t::laden(loadsave_t*) (simworld.cc:3776)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x55C1CE: convoi_t::step() (simconvoi.cc:743)
==8491==    by 0x5B1505: karte_t::step() (simworld.cc:2862)
==8491==    by 0x5B24DC: karte_t::interactive() (simworld.cc:4544)
==8491==    by 0x582B64: simu_main(int, char**) (simmain.cc:940)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491==  Address 0xF8F3B9F is 7 bytes inside a block of size 14 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x55EC46: convoi_t::rdwr(loadsave_t*) (simconvoi.cc:1711)
==8491==    by 0x561748: convoi_t::convoi_t(karte_t*, loadsave_t*) (simconvoi.cc:166)
==8491==    by 0x5B7D1D: karte_t::laden(loadsave_t*) (simworld.cc:3776)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491==    by 0x4DEDF3: gui_container_t::infowin_event(event_t const*) (gui_container.cc:90)
==8491== 
==8491== Conditional jump or move depends on uninitialised value(s)
==8491==    at 0x50752E1: (within /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x5075B37: (within /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x504C65A: SDL_PumpEvents (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x504CAA8: SDL_PollEvent (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x5EB165: internal_GetEvents(int) (simsys_s.cc:436)
==8491==    by 0x5EB789: GetEventsNoWait() (simsys_s.cc:636)
==8491==    by 0x56851A: display_poll_event(event_t*) (simevent.cc:177)
==8491==    by 0x5A5C78: win_poll_event(event_t*) (simwin.cc:977)
==8491==    by 0x5B2300: karte_t::interactive() (simworld.cc:4495)
==8491==    by 0x582B64: simu_main(int, char**) (simmain.cc:940)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491== 
==8491== Invalid read of size 8
==8491==    at 0x57BF73: simline_t::unregister_stops(schedule_t*) (simline.cc:209)
==8491==    by 0x57BFF1: simline_t::unregister_stops() (simline.cc:201)
==8491==    by 0x57C074: simline_t::remove_convoy(quickstone_tpl<convoi_t>) (simline.cc:134)
==8491==    by 0x555AE1: convoi_t::unset_line() (simconvoi.cc:2387)
==8491==    by 0x560B4D: convoi_t::~convoi_t() (simconvoi.cc:210)
==8491==    by 0x555F62: convoi_t::destroy() (simconvoi.cc:2297)
==8491==    by 0x5B62DD: karte_t::destroy() (simworld.cc:551)
==8491==    by 0x5B903B: karte_t::~karte_t() (simworld.cc:1577)
==8491==    by 0x582C2C: simu_main(int, char**) (simmain.cc:965)
==8491==    by 0x5EB04A: main (simsys_s.cc:719)
==8491==  Address 0xF9388D3 is 35 bytes inside a block of size 42 alloc'd
==8491==    at 0x4C22F75: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==8491==    by 0x4580AF: minivec_tpl<linieneintrag_t>::resize(unsigned) (minivec_tpl.h:34)
==8491==    by 0x457490: schedule_t::rdwr(loadsave_t*) (fahrplan.cc:233)
==8491==    by 0x57C546: simline_t::rdwr(loadsave_t*) (simline.cc:155)
==8491==    by 0x57E5A1: simlinemgmt_t::rdwr(karte_t*, loadsave_t*, spieler_t*) (simlinemgmt.cc:166)
==8491==    by 0x543782: spieler_t::rdwr(loadsave_t*) (simplay.cc:815)
==8491==    by 0x5B80A1: karte_t::laden(loadsave_t*) (simworld.cc:3800)
==8491==    by 0x5B8ECE: karte_t::laden(char const*) (simworld.cc:3507)
==8491==    by 0x4FC6EA: loadsave_frame_t::action(char const*) (loadsave_frame.cc:35)
==8491==    by 0x5130C3: savegame_frame_t::action_triggered(gui_action_creator_t*, value_t) (savegame_frame.cc:337)
==8491==    by 0x49AD2E: gui_action_creator_t::call_listeners(value_t) (gui_action_creator.h:36)
==8491==    by 0x49AB24: button_t::infowin_event(event_t const*) (gui_button.cc:310)
==8491== 
==8491== Conditional jump or move depends on uninitialised value(s)
==8491==    at 0x60167FD: _snd_pcm_direct_shm_discard (pcm_direct.c:156)
==8491==    by 0x601177E: snd_pcm_dmix_close (pcm_dmix.c:653)
==8491==    by 0x5FE5C44: snd_pcm_close (pcm.c:707)
==8491==    by 0x601A167: softvol_free (pcm_softvol.c:373)
==8491==    by 0x601A17F: snd_pcm_softvol_close (pcm_softvol.c:384)
==8491==    by 0x5FE5C44: snd_pcm_close (pcm.c:707)
==8491==    by 0x5FFE4EC: snd_pcm_plug_close (pcm_plug.c:71)
==8491==    by 0x5FE5C44: snd_pcm_close (pcm.c:707)
==8491==    by 0x507338A: (within /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x5047DC5: SDL_AudioQuit (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x5047324: SDL_QuitSubSystem (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491==    by 0x504737D: SDL_Quit (in /usr/lib64/libSDL-1.2.so.0.11.0)
==8491== 
==8491== ERROR SUMMARY: 2283 errors from 13 contexts (suppressed: 3 from 2)
==8491== malloc/free: in use at exit: 100,253,671 bytes in 124,565 blocks.
==8491== malloc/free: 183,905 allocs, 59,340 frees, 148,274,035 bytes allocated.
==8491== For counts of detected errors, rerun with: -v
==8491== searching for pointers to 124,565 not-freed blocks.
==8491== checked 68,117,632 bytes.
==8491== 
==8491== LEAK SUMMARY:
==8491==    definitely lost: 36,323 bytes in 4,508 blocks.
==8491==      possibly lost: 58,808 bytes in 820 blocks.
==8491==    still reachable: 100,158,540 bytes in 119,237 blocks.
==8491==         suppressed: 0 bytes in 0 blocks.
==8491== Rerun with --leak-check=full to see details of leaked memory.

Re: [Valgrind v5.0]

Reply #8 – July 16, 2009, 11:16:59 am

'Invalid read of size 8' are not good too

and It will be nice to eliminate memory leaks which valgrind shows.

Re: [Valgrind v5.0]

Reply #9 – July 16, 2009, 02:00:25 pm

The memory leak valgrind shows are mostly due to using our own memory allocation routines which makes it nearly impossible to return memory properly, since it means it must be only freed after all other objects have been freed. But this is nearly impossible, since some destructors are only called after the termination of the program.

Re: [Valgrind v5.0]

Reply #10 – July 16, 2009, 08:05:28 pm

Valgrind marks as 'definitely lost' only memory block which was allocated but not freed and there is no more pointers for this block in program. So this block can't be used anymore nor deleted. Valgrind can be cheated by hiding pointers by doing some arithmetic operations on them - but this is not common practise

- and very seldom it log false reports.
I look and check a few from log and they seem to be real memory leaks , even this one with zero bytes loses

Quote

0 bytes in 559 blocks are definitely lost in loss record 1 of 250

I know that most of problems are trivial one, but they still are bugs, and such great memory leak detection tool can help to find some more serious problems

Re: [Valgrind v5.0]

Reply #11 – July 17, 2009, 10:34:17 am

Quote from: Hanczar – on July 16, 2009, 08:05:28 pm

I know that most of problems are trivial one, but they still are bugs, and such great memory leak detection tool can help to find some more serious problems

I've used Valgrind in the past while I still was active, and I know Prissi and the others continued. Even if they do not jump at every report, it doesn't mean they ignore the tool and the reports - but maybe they do not think the reports are urgent enough to be fixed now.

I still don't like to see the unitialised reads there, and would like to have them fixed, since such leads to "random" crashes or errors, that users cannot properly report or reproduce.

Re: [Valgrind v5.0]

Reply #12 – July 17, 2009, 02:00:50 pm

Dwachs fixed most of them. They could just lkead to a convoi drawn for the very first time 128 pixel to the left/right etc. and thus could not have cuase crashes. But reads for spurious places are indeed not healthy. However, since SDL also contains quite some warnings, debugging with valgrind is not too easy.

Re: [Valgrind v5.0]

Reply #13 – July 17, 2009, 05:54:48 pm

I think these Invalid reads are due to data sizes that are not a multiple of 8. If the program reads then at the end of an array, the processor reads 8 bytes, where some of them are invalid. So this invalid reads cannot lead to crashes.

They can be fixed by changing the memory allocation in the templates.

Re: [Valgrind v5.0]

Reply #14 – July 17, 2009, 07:09:21 pm

Quote from: Dwachs – on July 17, 2009, 05:54:48 pm

I think these Invalid reads are due to data sizes that are not a multiple of 8.

That might explain the reports by valgrind. If I remember correctly, malloc is meant to at least reserve the size of the largest type, that'd be 8 bytes for a double or long long? maybe we should emulate this behaviour and round up allocations to the next full 8 bytes.

Re: [Valgrind v5.0]

Reply #15 – July 17, 2009, 08:44:52 pm

Malloc, as it is implemented now, will at least return 16Byte blocks, since the standard management routines require such an overhead. At least this is true for most 32Bit systems and the plain vanilla libaries, so I was told. Looking at the implementations flaoting around, this seems reasonable.

Re: [Valgrind v5.0]

Reply #16 – July 18, 2009, 09:08:31 pm

Version 5.1 (built from 2009VII18 sources ) crashes from time to time - in 20 min - 1h of play, with error from glibc about memory corruption.
I tried to catch this problem with valgrind but with no luck. Log from playing 5.1 version attached. It was centralized / decentralized / centralized switches during this play, but I don't see reports related to path searches.
Using uninitialized variables which developers from ST Standard corrected not occurs any more - thanks

- but some probably related to Experimental still exists.

Re: [Valgrind v5.0]

Reply #17 – July 18, 2009, 09:19:58 pm

Thank you for the report - were you doing anything in particular when the crashes occurred?

Re: [Valgrind v5.0]

Reply #18 – July 18, 2009, 09:50:42 pm

2x time exactly when I clicked on tram depot ( without any convoi ). Rest 3-4times I don't exactly remember, rather when I do usual actions on map ( scrolling , clicking on buildings , convoys ).
I'll try catch backtrace from such crash.

Re: [Valgrind v5.0]

Reply #19 – July 18, 2009, 10:07:26 pm

If you could (especially for the depot crash), I'd be extremely grateful.

Re: [Valgrind v5.0]

Reply #20 – July 18, 2009, 10:33:57 pm

I played more than one hour with disabled centralized path system, then I turn it on and after few minutes it crashed.

*** glibc detected *** /home/hanczar/workspace/simutrans-experimental-cpy/simutrans/sim: corrupted double-linked list: 0x09fd5280 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7c9c604]
/lib/tls/i686/cmov/libc.so.6[0xb7c9f5d2]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7ca09c5]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb7e7ff47]
/usr/lib/libstdc++.so.6(_Znaj+0x1d)[0xb7e8008d]
/home/hanczar/workspace/simutrans-experimental-cpy/simutrans/sim[0x81dcf56]
======= Memory map: ========

backtrace:

(gdb) bt
#0 0xb7f78430 in __kernel_vsyscall ()
#1 0xb7c586d0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7c5a098 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7c9624d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7c9c604 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7c9f5d2 in ?? () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7ca09c5 in malloc () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7e7ff47 in operator new () from /usr/lib/libstdc++.so.6
#8 0xb7e8008d in operator new[] () from /usr/lib/libstdc++.so.6
#9 0x081dcf56 in path_explorer_t::compartment_t::step (this=0x9f7957c) at path_explorer.cc:939
#10 0x081dd262 in path_explorer_t::step () at path_explorer.cc:82
#11 0x081cda75 in karte_t::step (this=0x9fd3c80) at simworld.cc:3002
#12 0x081ce4f8 in karte_t::interactive (this=0x9fd3c80) at simworld.cc:4743
#13 0x081a27c4 in simu_main (argc=704, argv=0xa9c7a58) at simmain.cc:957
#14 0x081ff788 in main (argc=1, argv=0xbfb93804) at simsys_s.cc:737

Re: [Valgrind v5.0]

Reply #21 – July 18, 2009, 11:50:42 pm

And this one occured exactly during click on truck depot. I have save game with decentralized path system, load it, played it about 20 min, enable centralized path system, and in two minutes during click on truck depot crash:

#0 0x0804d024 in einstellungen_t::get_use_timeline (this=0x73) at vehicle/../dataobj/einstellungen.h:396
(gdb) bt
#0 0x0804d024 in einstellungen_t::get_use_timeline (this=0x73) at vehicle/../dataobj/einstellungen.h:396
#1 0x0804d343 in karte_t::get_timeline_year_month (this=0x9c75218) at simworld.h:540
#2 0x080cde38 in gui_convoy_****embler_t::build_vehicle_lists (this=0xb1c64a8) at gui/components/gui_convoy_****embler.cc:481
#3 0x080edb75 in depot_frame_t::check_way_electrified (this=0xb1c5f20) at gui/depot_frame.cc:710
#4 0x080f0006 in depot_frame_t (this=0xb1c5f20, depot=0xa6cdd58) at gui/depot_frame.cc:50
#5 0x08182499 in depot_t::zeige_info (this=0xa6cdd58) at simdepot.cc:168
#6 0x081beb81 in wkz_abfrage_t::work (this=0x9ee9bd0, welt=0x9ca6c90, sp=0x9ca23b0, pos={x = 229, y = 81, z = 3 '\003', static invalid = {x = -1, y = -1, z = -1 'ÿ', static invalid = <same as static member of an already seen type>}}) at simwerkz.cc:342
#7 0x081cdfdf in karte_t::interactive_event (this=0x9ca6c90, ev=@0xbfb8beb8) at simworld.cc:4636
#8 0x081ce3bc in karte_t::interactive (this=0x9ca6c90) at simworld.cc:4769
#9 0x081a27c4 in simu_main (argc=704, argv=0xa69bcd8) at simmain.cc:957
#10 0x081ff788 in main (argc=1, argv=0xbfb8dff4) at simsys_s.cc:737

(gdb) frame 0
#0 0x0804d024 in einstellungen_t::get_use_timeline (this=0x73) at vehicle/../dataobj/einstellungen.h:396
(gdb) frame 1
#1 0x0804d343 in karte_t::get_timeline_year_month (this=0x9c75218) at simworld.h:540
(gdb) print einstellungen
$3 = (einstellungen_t *) 0x73

so pointer for einstellungen in karte_t was invalid, maybe together with some memory area corrupted.

Re: [Valgrind v5.0]

Reply #22 – July 19, 2009, 06:38:03 am

Hi Hanczar

Thank you very much for your efforts indeed

But regarding the following crash which originates from the centralised path searching code :

Quote from: Hanczar – on July 18, 2009, 10:33:57 pm

I played more than one hour with disabled centralized path system, then I turn it on and after few minutes it crashed.

*** glibc detected *** /home/hanczar/workspace/simutrans-experimental-cpy/simutrans/sim: corrupted double-linked list: 0x09fd5280 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7c9c604]
/lib/tls/i686/cmov/libc.so.6[0xb7c9f5d2]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7ca09c5]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb7e7ff47]
/usr/lib/libstdc++.so.6(_Znaj+0x1d)[0xb7e8008d]
/home/hanczar/workspace/simutrans-experimental-cpy/simutrans/sim[0x81dcf56]
======= Memory map: ========

backtrace:

(gdb) bt
#0 0xb7f78430 in __kernel_vsyscall ()
#1 0xb7c586d0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7c5a098 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7c9624d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7c9c604 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7c9f5d2 in ?? () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7ca09c5 in malloc () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7e7ff47 in operator new () from /usr/lib/libstdc++.so.6
#8 0xb7e8008d in operator new[] () from /usr/lib/libstdc++.so.6
#9 0x081dcf56 in path_explorer_t::compartment_t::step (this=0x9f7957c) at path_explorer.cc:939
#10 0x081dd262 in path_explorer_t::step () at path_explorer.cc:82
#11 0x081cda75 in karte_t::step (this=0x9fd3c80) at simworld.cc:3002
#12 0x081ce4f8 in karte_t::interactive (this=0x9fd3c80) at simworld.cc:4743
#13 0x081a27c4 in simu_main (argc=704, argv=0xa9c7a58) at simmain.cc:957
#14 0x081ff788 in main (argc=1, argv=0xbfb93804) at simsys_s.cc:737

I must say I have no idea why it can happen.

Line 939 in path_explorer.cc only creates an array of objects. Since the cause of crash is the new operator but not the ****ignment operation, the only possible bug is that the array size is zero. However, this has already been checked and guarded against.

As you can see from the backtrace, the bug goes all the way down to c++ library code. Besides, the error message "corrupted double-linked list: 0x09fd5280" does not seem to have any relation to the path searching code.

Obviously, this bug is not caused by Line 939, but it has nevertheless triggered it. The real culprit may be some other centralised path searching code, but it can also be caused by other unrelated code.

Incidentally, Colin will help to test out the Windows version, so let's see if he encounters crashes then.

Re: [Valgrind v5.0]

Reply #23 – July 19, 2009, 10:17:05 am

Quote

Obviously, this bug is not caused by Line 939, but it has nevertheless triggered it. The real culprit may be some other centralised path searching code, but it can also be caused by other unrelated code.

Yes, this backtrace tells only that during this allocation from line 939, corruption memory in glibc was detected, and completely other part of program can do it. Although high probability is that is related to centralised path system I think.

Quote

for (uint16 i = 0; i < working_halt_count; i++)
{
transport_matrix = new transport_element_t[working_halt_count];
}

I sry, I didn't put it at once in previous comment, when it occured I checked variables, and they was : working_halt_count = 24 and i = 13.

Re: [Valgrind v5.0]

Reply #24 – July 19, 2009, 11:34:50 am

Quote from: Hanczar – on July 19, 2009, 10:17:05 am

Yes, this backtrace tells only that during this allocation from line 939, corruption memory in glibc was detected, and completely other part of program can do it. Although high probability is that is related to centralised path system I think.

I will take a look at the code again, but I don't think there is any indicative evidence to suggest that the centralised path searching code is the cause of such crashes. If memory is corrupted, any routine trying to allocate a new piece of memory on heap may trigger the crash.

The reason why distributed path searching system doesn't have this problem is that, it uses freelist for allocating new memory. So, even if memory is somehow corrupted, the problem may not be triggered, because it only reuses old memory pieces.

Besides, Colin just sent me an email, saying that the game has been running smoothly without any crash using centralised path searching system.

Re: [Valgrind v5.0]

Reply #25 – July 19, 2009, 11:57:37 am

Knightly,

could the new system also use Freelist?

Re: [Valgrind v5.0]

Reply #26 – July 19, 2009, 12:35:52 pm

James,

Quote from: jamespetts – on July 19, 2009, 11:57:37 am

could the new system also use Freelist?

Thank you very much for your suggestion, but the new system uses arrays instead of individual elements, and the arrays are of various sizes (depending on halt count) and their sizes are usually larger than what freelist handles. So, freelist isn't a suitable choice.

I know you are quite busy with Pak128.Britain Experimental now, but can you spare some time to track down the bug that causes the depot crash? Maybe the same bug that corrupts the memory causes both crashes.

Thank a lot in advance!

Re: [Valgrind v5.0]

Reply #27 – July 19, 2009, 12:50:48 pm

Ahh, I see. As to the depot crash, I suspect that it is the same as the depot crash that was reported before: it is impossible to track down because it cannot be reproduced when a debugger is running.

Re: [Valgrind v5.0]

Reply #28 – July 19, 2009, 01:20:45 pm

Quote from: jamespetts – on July 19, 2009, 12:50:48 pm

Ahh, I see. As to the depot crash, I suspect that it is the same as the depot crash that was reported before: it is impossible to track down because it cannot be reproduced when a debugger is running.

Actually, I have tried to reproduce the depot crash using your v5.1 SDL release build, but also in vain after several different attempts.

This is really an elusive bug. $:-\$

Re: [Valgrind v5.0]

Reply #29 – July 19, 2009, 02:45:38 pm

I know :-(

Re: [Valgrind v5.0]

Reply #30 – July 19, 2009, 02:48:25 pm

Quote from: jamespetts – on July 19, 2009, 12:50:48 pm

it is impossible to track down because it cannot be reproduced when a debugger is running.

Can't you track it with valgrind?

Re: [Valgrind v5.0]

Reply #31 – July 19, 2009, 04:11:51 pm

I can't run Valgrind, because I don't use Linux on the computer on which I develop Simutrans. Thank you for the suggestion, though :-)

Re: [Valgrind v5.0]

Reply #32 – July 22, 2009, 05:17:18 pm

James,

Have you gone through Hanczar's Valgrind report for v5.1 in details and fix the reported problems?

If not, please spare some time to do so, otherwise Hanczar's efforts would be wasted.

Knightly

Re: [Valgrind v5.0]

Reply #33 – July 24, 2009, 09:29:53 pm

I attach trivial patch which removes like 90% valgrinds reports related to Simutrans Experimental. It only adds initialization of three variables with zeros in vehikel_t constructors as it seems that they are later used in ****umption that they initial state is zero.

EDIT: proper patch in attachment

Re: [Valgrind v5.0]

Reply #34 – July 24, 2009, 10:52:41 pm

Thank you very much for that - it is most appreciated :-)