News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

[Bug] Crash when loading pak256-ex

Started by ceeac, August 05, 2020, 01:45:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ceeac

The crash happens with any program version I tried (including latest master) and pak256-ex 2.0.2 and 2.0.3.
This does not happen when loading pak128 nightly.

Backtrace:

=================================================================
==43452==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d00001c838 at pc 0x00000126bbf8 bp 0x7ffe1c8dcf70 sp 0x7ffe1c8dcf68
READ of size 4 at 0x60d00001c838 thread T0
    #0 0x126bbf7 in building_desc_t::set_scale(unsigned short) /home/ceeac/Projects/code/simutrans-ex/./bauer/../descriptor/building_desc.h:415:33
    #1 0x126bbf7 in karte_t::set_scale() /home/ceeac/Projects/code/simutrans-ex/simworld.cc:3238:49
    #2 0x1269655 in karte_t::karte_t() /home/ceeac/Projects/code/simutrans-ex/simworld.cc:3135:2
    #3 0x11339e9 in simu_main(int, char**) /home/ceeac/Projects/code/simutrans-ex/simmain.cc:1219:22
    #4 0x1190572 in sysmain(int, char**) /home/ceeac/Projects/code/simutrans-ex/simsys.cc:830:9
    #5 0x7fd7e01d40b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    #6 0x44510d in _start (/media/ceeac/Projects/code/simutrans-ex/build/default/simutrans-extended+0x44510d)

0x60d00001c838 is located 40 bytes inside of 136-byte region [0x60d00001c810,0x60d00001c898)
freed by thread T0 here:
    #0 0x4ed81d in operator delete(void*) (/media/ceeac/Projects/code/simutrans-ex/build/default/simutrans-extended+0x4ed81d)
    #1 0x52eab5 in obj_desc_t::operator delete(void*) /home/ceeac/Projects/code/simutrans-ex/bauer/../descriptor/obj_desc.h:44:10
    #2 0x52eab5 in hausbauer_t::register_desc(building_desc_t*) /home/ceeac/Projects/code/simutrans-ex/bauer/hausbauer.cc:232:3

previously allocated by thread T0 here:
    #0 0x4ecfbd in operator new(unsigned long) (/media/ceeac/Projects/code/simutrans-ex/build/default/simutrans-extended+0x4ecfbd)
    #1 0x5ed2c9 in obj_desc_t::operator new(unsigned long) /home/ceeac/Projects/code/simutrans-ex/descriptor/reader/../../bauer/../descriptor/obj_desc.h:29:10
    #2 0x5ed2c9 in building_reader_t::read_node(_IO_FILE*, obj_node_info_t&) /home/ceeac/Projects/code/simutrans-ex/descriptor/reader/building_reader.cc:216:26
    #3 0x61bd64 in obj_reader_t::read_nodes(_IO_FILE*, obj_desc_t*&, int, unsigned int) /home/ceeac/Projects/code/simutrans-ex/descriptor/reader/obj_reader.cc:240:18
    #4 0x61be4e in obj_reader_t::read_nodes(_IO_FILE*, obj_desc_t*&, int, unsigned int) /home/ceeac/Projects/code/simutrans-ex/descriptor/reader/obj_reader.cc:244:5
    #5 0x61b709 in obj_reader_t::read_file(char const*) /home/ceeac/Projects/code/simutrans-ex/descriptor/reader/obj_reader.cc:200:4
    #6 0x61a777 in obj_reader_t::load(char const*, char const*) /home/ceeac/Projects/code/simutrans-ex/descriptor/reader/obj_reader.cc:152:4
    #7 0x113253b in simu_main(int, char**) /home/ceeac/Projects/code/simutrans-ex/simmain.cc:1064:2
    #8 0x1190572 in sysmain(int, char**) /home/ceeac/Projects/code/simutrans-ex/simsys.cc:830:9
    #9 0x7fd7e01d40b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-use-after-free /home/ceeac/Projects/code/simutrans-ex/./bauer/../descriptor/building_desc.h:415:33 in building_desc_t::set_scale(unsigned short)
Shadow bytes around the buggy address:
  0x0c1a7fffb8b0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1a7fffb8c0: 00 00 00 00 00 00 fa fa fa fa fa fa fa fa 00 00
  0x0c1a7fffb8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
  0x0c1a7fffb8e0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1a7fffb8f0: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
=>0x0c1a7fffb900: fa fa fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd
  0x0c1a7fffb910: fd fd fd fa fa fa fa fa fa fa fa fa fd fd fd fd
  0x0c1a7fffb920: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa
  0x0c1a7fffb930: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00
  0x0c1a7fffb940: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
  0x0c1a7fffb950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==43452==ABORTING

Phystam

If you have trouble, please delete "demo.sve" and restart it.

ceeac


jamespetts

I am afraid that I cannot reproduce this with Pak.256 2.0.3. Ceeac - are you able to give any more detailed information on the circumstances in which this can be reproduced?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ceeac

I can reproduce it every time when compiling on Linux with -fsanitize=address and pak256-ex from here.

This seems to be related to overlaid/duplicate objects: When encountering a duplicate object in hausbauer_t::register_desc, the old descriptor is deleted, however hausbauer_t::modifiable_station_buildings still holds a pointer to the (now invalid) old descriptor.

jamespetts

This would suggest that the problem arises in code shared with Standard.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

It is very likely that this or something very simmilar does also affect standard.
When I did my adusted version of pak128, I encountered used the addon system to overlay the adusted obects.
I encountered and reported crashes when overlaying tunnels.
As far as I know that bug was never fixed.

prissi

I would like to test this is standard, but since there are no sources, I cannot do that. If you blame standard for a bug, you should at least provide a testing case.

Moreover, hausbauer_t::modifiable_station_buildings  does not exist in standard, which suggest rather bad bookkeeping in extended. For such cases the pointer should be allocated in "bool hausbauer_t::successfully_loaded()", which finalizes the objects. This routine is acalled after all overloading. (Depending on the state of extended, it may be also called "laden_abschliessen"

Ranran(retired)

I can't reproduce the crash even in my environment, however, I think pak.256 may have problems with fastforward as well.

I don't know if it is a pakset specific problem or a system problem. But the behavior is unusual.
Especially in debug build, fast-forward works like static. The 64-bit version of nightly build stops every 1 second.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Mariculous

Quote from: prissi on August 08, 2020, 11:54:13 AMIf you blame standard for a bug, you should at least provide a testing case.
Just to clarify, I did not blame standard.
I said it is very likely that standard is affected by this either, because I have observed and reported the same symptoms related to overlaid obects in standard a few years ago either.

In fact, it might or might not be affected. I don't care as I am not building any standard obects that overrdide existing ones anymore.

ceeac

For Standard, copying the whole pak64 folder to the addon folder (so every object is overlaid) results in this:

=================================================================
==22300==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000030c20 at pc 0x000000a8c7fc bp 0x7ffdf25d4a10 sp 0x7ffdf25d4a08
READ of size 8 at 0x608000030c20 thread T0
    #0 0xa8c7fb in tool_selector_t::add_tool_selector(tool_t*) /home/ceeac/Projects/code/simutrans/gui/tool_selector.cc:45:31
    #1 0x540830 in tunnel_builder_t::fill_menu(tool_selector_t*, waytype_t, short) /home/ceeac/Projects/code/simutrans/bauer/tunnelbauer.cc:127:18
    #2 0xfb2a66 in toolbar_t::update(player_t*) /home/ceeac/Projects/code/simutrans/simmenu.cc:880:6
    #3 0xfb056a in tool_t::update_toolbars() /home/ceeac/Projects/code/simutrans/simmenu.cc:750:7
    #4 0x10926db in karte_t::enlarge_map(settings_t const*, signed char const*) /home/ceeac/Projects/code/simutrans/simworld.cc:2029:2
    #5 0x108bdf4 in karte_t::init(settings_t*, signed char const*) /home/ceeac/Projects/code/simutrans/simworld.cc:1270:2
    #6 0xfa3a70 in simu_main(int, char**) /home/ceeac/Projects/code/simutrans/simmain.cc:1346:9
    #7 0x11cb34f in sysmain(int, char**) /home/ceeac/Projects/code/simutrans/sys/simsys.cc:1098:9
    #8 0x12582a1 in main /home/ceeac/Projects/code/simutrans/sys/simsys_s2.cc:790:9
    #9 0x7fb0f8f690b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    #10 0x42631d in _start (/media/ceeac/Projects/code/simutrans/build/default/sim+0x42631d)

0x608000030c20 is located 0 bytes inside of 96-byte region [0x608000030c20,0x608000030c80)
freed by thread T0 here:
    #0 0x4cea2d in operator delete(void*) (/media/ceeac/Projects/code/simutrans/build/default/sim+0x4cea2d)
    #1 0x106eaf7 in tool_build_tunnel_t::~tool_build_tunnel_t() /home/ceeac/Projects/code/simutrans/./simtool.h:323:7
    #2 0x53f94c in tunnel_builder_t::register_desc(tunnel_desc_t*) /home/ceeac/Projects/code/simutrans/bauer/tunnelbauer.cc:49:3
    #3 0x6e4a90 in tunnel_reader_t::register_obj(obj_desc_t*&) /home/ceeac/Projects/code/simutrans/descriptor/reader/tunnel_reader.cc:29:2
    #4 0x6ca89f in obj_reader_t::read_nodes(_IO_FILE*, obj_desc_t*&, int, unsigned int) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:255:12
    #5 0x6ca7a8 in obj_reader_t::read_nodes(_IO_FILE*, obj_desc_t*&, int, unsigned int) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:248:5
    #6 0x6ca0c9 in obj_reader_t::read_file(char const*) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:205:4
    #7 0x6c9aa3 in obj_reader_t::load(char const*, char const*) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:158:4
    #8 0xfa13cd in simu_main(int, char**) /home/ceeac/Projects/code/simutrans/simmain.cc:1096:7
    #9 0x11cb34f in sysmain(int, char**) /home/ceeac/Projects/code/simutrans/sys/simsys.cc:1098:9
    #10 0x12582a1 in main /home/ceeac/Projects/code/simutrans/sys/simsys_s2.cc:790:9
    #11 0x7fb0f8f690b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16

previously allocated by thread T0 here:
    #0 0x4ce1cd in operator new(unsigned long) (/media/ceeac/Projects/code/simutrans/build/default/sim+0x4ce1cd)
    #1 0x53f95b in tunnel_builder_t::register_desc(tunnel_desc_t*) /home/ceeac/Projects/code/simutrans/bauer/tunnelbauer.cc:53:30
    #2 0x6e4a90 in tunnel_reader_t::register_obj(obj_desc_t*&) /home/ceeac/Projects/code/simutrans/descriptor/reader/tunnel_reader.cc:29:2
    #3 0x6ca89f in obj_reader_t::read_nodes(_IO_FILE*, obj_desc_t*&, int, unsigned int) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:255:12
    #4 0x6ca7a8 in obj_reader_t::read_nodes(_IO_FILE*, obj_desc_t*&, int, unsigned int) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:248:5
    #5 0x6ca0c9 in obj_reader_t::read_file(char const*) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:205:4
    #6 0x6c9aa3 in obj_reader_t::load(char const*, char const*) /home/ceeac/Projects/code/simutrans/descriptor/reader/obj_reader.cc:158:4
    #7 0xfa0fe7 in simu_main(int, char**) /home/ceeac/Projects/code/simutrans/simmain.cc:1085:2
    #8 0x11cb34f in sysmain(int, char**) /home/ceeac/Projects/code/simutrans/sys/simsys.cc:1098:9
    #9 0x12582a1 in main /home/ceeac/Projects/code/simutrans/sys/simsys_s2.cc:790:9
    #10 0x7fb0f8f690b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-use-after-free /home/ceeac/Projects/code/simutrans/gui/tool_selector.cc:45:31 in tool_selector_t::add_tool_selector(tool_t*)
Shadow bytes around the buggy address:
  0x0c107fffe130: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c107fffe140: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x0c107fffe150: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c107fffe160: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x0c107fffe170: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c107fffe180: fa fa fa fa[fd]fd fd fd fd fd fd fd fd fd fd fd
  0x0c107fffe190: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c107fffe1a0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x0c107fffe1b0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c107fffe1c0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x0c107fffe1d0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 04
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==22300==ABORTING

This is very likely the bug Freahk mentioned. Since these are two different bugs, maybe it makes sense to split the topic (although I do not know if the bug from this post is also present in Extended since it crashes beforehand).

prissi

#11
Thank you, this was most helpful. Fixed in r9181.

Indeed, in standard the creation of tools was in register_desc instead in sucessfully_loaded(). Added those to bridge and tunnel builder, and corrected the way builder sucessfully_loaded. A similar could be done for extended.

EDIT: I think r9181 should apply to extended without conflicts (apart from renaming). This should give a clear indication where to add/update  hausbauer_t::modifiable_station_buildings (in hausbauer_t::sucessfully_loaded() )

ceeac

Should now also be fixed for Extended: #244.

jamespetts

Quote from: ceeac on August 12, 2020, 11:38:13 AM
Should now also be fixed for Extended: #244.

Splendid, thank you: now incorporated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

TurfIt

Do note the proper fix for this in r9197.