News:

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

pak128.cs-ex segfault

Started by Vladki, April 10, 2019, 08:31:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

After a long time I wanted to check how pak128.CS behaves under extended... I have recompiled with latest makeobj-extended (compiled by myself, as the one from nightly builds depends on older version of libpng), and when I start simutrans with it, I get segfault. If I do not load any game it complains about rivers or water:


Calculating textures ...done
Warning: karte_t::create_rivers():      Too many rivers requested! (only 0 rivers placed)
Creating cities ...
Neoprávněný přístup do paměti (SIGSEGV)


If I try to load some old savegame from command line, it fails in different way:

Calculating textures ...done
Message: karte_t::load():       Prepare for loading
Message: karte_t::load():       Time is now: 13138
World destroyed.
Warning: karte_t::load: Fileversion: 120004
Message: uint32 haltestelle_t::get_service_frequency(halthandle_t destination, uint8 category) const:   Service frequency not in the database: calculating
.... many times.....
Message: uint32 haltestelle_t::get_service_frequency(halthandle_t destination, uint8 category) const:   Service frequency not in the database: calculating
Warning: karte_t::load():       loaded savegame from 7/1903, next month=142606336, ticks=142046283 (per month=1<<21)
Neoprávněný přístup do paměti (SIGSEGV)


Therefore I think it the problem is not in water or rivers..

Strace:

write(2, "Warning: karte_t::load():\t", 26Warning: karte_t::load():     ) = 26
write(2, "loaded savegame from 7/1903, nex"..., 84loaded savegame from 7/1903, next month=142606336, ticks=142046283 (per month=1<<21)) = 84
write(2, "\n", 1
)                       = 1
close(16)                               = 0
clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=9584, tv_nsec=427498673}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++


or without -load

write(2, "Message: karte_t::create_rivers("..., 35Message: karte_t::create_rivers():    ) = 35
write(2, "There aren't any water tiles!\n", 30There aren't any water tiles!
) = 30
write(2, "\n", 1
)                       = 1
write(2, "Creating cities ...", 19Creating cities ...)     = 19
write(2, "\n", 1
)                       = 1
write(2, "Creating cities: 1", 18Creating cities: 1)      = 18
write(2, "\n", 1
)                       = 1
clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=9635, tv_nsec=123643334}) = 0
clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=9635, tv_nsec=123904501}) = 0
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="#\224v\1\0\0\0\0\2\0\0\0\r\0\0\7\n\0\0\7[\0\0\0\16\0\0\7\17\0\0\7"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 72
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=9635, tv_nsec=124126185}) = 0
ioctl(5, DRM_IOCTL_I915_GEM_BUSY, 0x7ffe6f583be0) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583a20) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583a20) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583a20) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583a20) = 0
ioctl(5, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffe6f583d60) = 0
ioctl(5, DRM_IOCTL_I915_GEM_BUSY, 0x7ffe6f583830) = 0
ioctl(5, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffe6f583820) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583840) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffe6f583fa0) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffe6f583fb0) = 0
ioctl(5, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffe6f583f40) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583fb0) = 0
ioctl(5, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffe6f583f30) = 0
ioctl(5, DRM_IOCTL_I915_GEM_BUSY, 0x7ffe6f583f00) = 0
ioctl(5, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffe6f583ef0) = 0
ioctl(5, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffe6f583f10) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\224\1\22\0\n\0\0\7\16\0\0\7\\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=72}], 1) = 72
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++



Pakset can be downloaded http://list.extended.simutrans.org/pak128.CS-Ex.zip
Sources are at sourceforge: https://sourceforge.net/p/simutrans/code/HEAD/tree/pak128.CS/

jamespetts

My apologies for the delayed response in relation to this. The problem that I get on loading the pakset appears to be related to menuconf.tab: there is a toolbar somewhere set to zero, which will cause a fatal error. All entries of the type@


toolbar[x]=y


must have a value for x that is greater than zero.

I hope that this helps.
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.

Vladki

#2
Thanks James for the hint to menuconf.tab.
However toolbar[0] is perfectly OK, it is the main menu.
The problem was due to numbering conflict between standard and extended, (reported here: https://forum.simutrans.com/index.php/topic,18586.msg176503.html#msg176503), code 40 is
used for different purposes. In standard it is TOOL_ROTATE_BUILDING (really a general_tool), while in extended it is TOOL_BUILD_SIGNALBOX, which is not a tool by itself, and signalboxes are listed in menu by
toolbar[2][11]=buildings(70,0). There is one more extra thing in standard - last used toolbar, toolbar[0][40]=toolbar[LAST_USED],24,z,Last used tools,  which even if not implemented does not cause any problems.

Also the tool 41 is in standard used to merge stations, so it is another code conflict. And I might have missed some other news

# Standard
# TOOL_ROTATE_BUILDING =  40
# Extended
# TOOL_BUILD_SIGNALBOX =  40
# TOOL_REASSIGN_SIGNAL =  41

I had to split the menuconf for standard and extended:

diff -u pak128.CS/config/menuconf.tab pak128.CS-Ex/config/menuconf.tab
--- pak128.CS/config/menuconf.tab       2018-09-13 01:29:03.406106294 +0200
+++ pak128.CS-Ex/config/menuconf.tab    2019-04-24 15:14:57.324411720 +0200
@@ -116,7 +116,7 @@
general_tool[34]=,,11,
general_tool[35]=16,13,11,K
# cityroad (36) not set up here
-general_tool[40]=20,11,11,@
+general_tool[41]=19,6,11,\

# SECOND SECTION: simple tools
@@ -503,8 +503,8 @@
toolbar[10][12]=general_tool[35]
toolbar[10][13]=simple_tool[5]
toolbar[10][14]=dialog_tool[6]
-toolbar[10][15]=general_tool[40]      # Only for standard
+toolbar[10][15]=general_tool[41]       # Only for extended



jamespetts

Interesting - thank you for that. I wonder when these tools were added to 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.

ACarlotti

They were added in r8481 (June 2018) and r8715 (March 2019).

I think we need renumber these (and other tools added to Extended only) - perhaps a good strategy would be to renumber them to start at 128, but to temporarily make them available under the old numbers as well so as not to immediately break existing configs ('temporarily' meaning 'only until the conflicting changes are merged from Standard').

I've also noticed the OTRP changes last year changed the numbers allocated to the existing tools listed in the enum as TOOL_RECOLOUR_TOOL and TOOL_ACCESS_TOOL (by inserting TOOL_SHOW_RIBI and TOOL_CHANGE_ROADSIGN before them). I don't know if this has caused any issues as a result.

jamespetts

I have not looked into tool numbering recently - it is a potentially complex issue that requires detailed consideration of all usages. The TOOL_RECOLOUR_TOOL and TOOL_ACCESS_TOOL I believe are Extended specific. If these do follow consecutively from Standard tools, they may well end up being renumbered whenever Standard adds tools - but quite how to do backwards compatibility is far from straightforward.
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.

prissi

One always could add as much dummy tools to the array until tool 128 is then extended specific ...

Vladki

Is it not possible to have gaps in tool numbers?

ACarlotti

I've pushed a change to tool numbers to my Github master. Under this change, the vector of tools is extended to 128+num_extended_tools, with dummy_tool padding the gap. The old tool numbers will remain available until the same-numbered tool is merged from Standard; there is a warning given if a pakset is using the old tool numbers and not the new ones.

I think this should resolve most issues, although there may still be some anomalies with trying to use the same menuconf for both Extended and Standard, whereby references to the Standard-only tools will currently be treated as references to the deprecated Extended tool numbers.

jamespetts

Thank you - that is very helpful. I have now incorporated this. I have also updated the menuconf.tab of Pak128.Britain-Ex to use the non-deprecated numberings.
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.