The International Simutrans Forum

 

Author Topic: pak128.cs-ex segfault  (Read 569 times)

0 Members and 1 Guest are viewing this topic.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2634
    • My addons, mostly roadsigns
  • Languages: EN, CS
pak128.cs-ex segfault
« on: April 10, 2019, 08:31:38 PM »
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:

Code: [Select]
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:

Code: [Select]
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:

Code: [Select]
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

Code: [Select]
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/

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: pak128.cs-ex segfault
« Reply #1 on: April 22, 2019, 11:29:15 PM »
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@

Code: [Select]
toolbar[x]=y
 must have a value for x that is greater than zero.

I hope that this helps.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2634
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: pak128.cs-ex segfault
« Reply #2 on: April 24, 2019, 01:32:25 PM »
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:

Code: [Select]
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
 
« Last Edit: April 24, 2019, 02:21:08 PM by Vladki »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: pak128.cs-ex segfault
« Reply #3 on: April 30, 2019, 09:53:10 PM »
Interesting - thank you for that. I wonder when these tools were added to Standard?

Offline ACarlotti

  • *
  • Posts: 444
Re: pak128.cs-ex segfault
« Reply #4 on: May 01, 2019, 01:30:43 AM »
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: pak128.cs-ex segfault
« Reply #5 on: May 31, 2019, 12:25:14 PM »
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.

Online prissi

  • Developer
  • Administrator
  • *
  • Posts: 9460
  • Languages: De,EN,JP
Re: pak128.cs-ex segfault
« Reply #6 on: June 03, 2019, 05:11:17 AM »
One always could add as much dummy tools to the array until tool 128 is then extended specific ...

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2634
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: pak128.cs-ex segfault
« Reply #7 on: June 03, 2019, 06:50:53 AM »
Is it not possible to have gaps in tool numbers?

Offline ACarlotti

  • *
  • Posts: 444
Re: pak128.cs-ex segfault
« Reply #8 on: June 03, 2019, 04:43:45 PM »
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: pak128.cs-ex segfault
« Reply #9 on: June 04, 2019, 10:23:11 PM »
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.