Runtime issues in Debian

[rtentser]

When i try to run openmom i get "Floating point exception". So i've run it with gdb and got this:

(gdb) run

Starting program: /home/rtentser/Sources/cmake/src/openmom 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Program received signal SIGFPE, Arithmetic exception.
0x0830c3bd in std::__detail::_Mod_range_hashing::operator() (this=0x864142c <i18n::data[abi:cxx11]>, __num=170, __den=0)
    at /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/hashtable_policy.h:446
446     { return __num % __den; }

(gdb) backtrace

#0  0x0830c3bd in std::__detail::_Mod_range_hashing::operator() (this=0x864142c <i18n::data[abi:cxx11]>, __num=170, __den=0)
    at /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/hashtable_policy.h:446
#1  0x0830c370 in std::__detail::_Hash_code_base<I18, std::pair<I18 const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Select1st, enum_hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, true>::_M_bucket_index (this=0x864142c <i18n::data[abi:cxx11]>, __c=170, __n=0)
    at /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/hashtable_policy.h:1260
#2  0x0830be7b in std::_Hashtable<I18, std::pair<I18 const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<I18 const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::__detail::_Select1st, std::equal_to<I18>, enum_hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_bucket_index (
    this=0x864142c <i18n::data[abi:cxx11]>, __k=@0xbffff13c: I18::FIRST_AVAILABLE_INDEX, __c=170)
    at /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/hashtable.h:623
#3  0x0830bd28 in std::__detail::_Map_base<I18, std::pair<I18 const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<I18 const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::__detail::_Select1st, std::equal_to<I18>, enum_hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true>, true>::operator[] (
    this=0x864142c <i18n::data[abi:cxx11]>, __k=@0xbffff13c: I18::FIRST_AVAILABLE_INDEX)
    at /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/hashtable_policy.h:590
#4  0x0830bcd4 in std::unordered_map<I18, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, enum_hash, std::equal_to<I18>, std::allocator<std::pair<I18 const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::operator[] (this=0x864142c <i18n::data[abi:cxx11]>, __k=@0xbffff13c: I18::FIRST_AVAILABLE_INDEX)
    at /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/unordered_map.h:904
#5  0x0844fd4e in i18n::keyForString (key="messages_place_name_ruins_first")
    at /home/rtentser/Sources/openmom/src/i18n/Localization.cpp:32
#6  0x082c5850 in __cxx_global_var_init () at /home/rtentser/Sources/openmom/src/ui/GfxData.cpp:34
#7  0x082c6afb in _GLOBAL__sub_I_GfxData.cpp ()
#8  0x08531a4b in __libc_csu_init ()
#9  0xb7ab8216 in __libc_start_main (main=0x82d7fc0 <main(int, char**)>, argc=1, argv=0xbffff364, init=0x8531a00 <__libc_csu_init>, 
    fini=0x8531a60 <__libc_csu_fini>, rtld_fini=0xb7feb070 <_dl_fini>, stack_end=0xbffff35c) at ../csu/libc-start.c:247
#10 0x082d7ee9 in _start ()

[Jakz]

I think this may have something to do with static initialization order of variables, i18n::keyForString is called by a static constructor in GfxData.cpp but the static std:unordered_map used by localization is not initialized yet.

[rtentser]

New bug:

rtentser@desktop:~/Sources/cmake$ src/openmom

lbx file at ../../data/yaml/english.yaml not found
openmom: /home/rtentser/Sources/openmom/src/save/YAML.cpp:144: static Path yaml::yamlPath(const std::string &): Assertion `false' failed.
Aborted

rtentser@desktop:~/Sources/cmake$ gdb src/openmom (gdb) run

Starting program: /home/rtentser/Sources/cmake/src/openmom 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
lbx file at ../../data/yaml/english.yaml not found
openmom: /home/rtentser/Sources/openmom/src/save/YAML.cpp:144: static Path yaml::yamlPath(const std::string &): Assertion `false' failed.

Program received signal SIGABRT, Aborted.
0xb7fd9cf9 in __kernel_vsyscall ()

(gdb) backtrace

#0  0xb7fd9cf9 in __kernel_vsyscall ()
#1  0xb7accdd0 in __libc_signal_restore_set (set=0xbfffebe0) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7ace297 in __GI_abort () at abort.c:89
#4  0xb7ac5a27 in __assert_fail_base (fmt=0xb7c01614 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x85377b2 "false", 
    file=0x85479dd "/home/rtentser/Sources/openmom/src/save/YAML.cpp", line=144, 
    function=0x8547a0e "static Path yaml::yamlPath(const std::string &)") at assert.c:92
#5  0xb7ac5aab in __GI___assert_fail (assertion=0x85377b2 "false", file=0x85479dd "/home/rtentser/Sources/openmom/src/save/YAML.cpp", 
    line=144, function=0x8547a0e "static Path yaml::yamlPath(const std::string &)") at assert.c:101
#6  0x08491fc8 in yaml::yamlPath (fileName="english.yaml") at /home/rtentser/Sources/openmom/src/save/YAML.cpp:144
#7  0x08491abf in yaml::parse (fileName="english.yaml") at /home/rtentser/Sources/openmom/src/save/YAML.cpp:113
#8  0x084a0d7e in yaml::parseLocalization () at /home/rtentser/Sources/openmom/src/save/YAML.cpp:1178
#9  0x084a105b in yaml::parse () at /home/rtentser/Sources/openmom/src/save/YAML.cpp:1191
#10 0x082d7ca2 in main (argc=1, arg=0xbffff374) at /home/rtentser/Sources/openmom/src/main.cpp:26

I've copied LBX files to data/lbx of source code before a build. I'm not sure if openmom sees them from the cmake configuration directory.

Also about lbx files. There can be case trouble: Master of Magic data files in gog installer for linux is in upper case and i don't know which case you use. I'm not sure it's the problem now, but i think it's worth checking. Can you make names of data files case insensitive (if not already)?

[Jakz]

Currently you can adjust the relative path from the executable from unix.cpp, as you can see now it looks for

lbx file at ../../data/yaml/english.yaml not found

Now I don't know where your binary resides exactly but you can easily adjust their relative path either on file system or in unix.cpp!

[rtentser]

I 've changed getResourcePath to absolute and to relative for directory from which i start openmom. With them (one of them, not simultaneously) the engine starts!

But that happens if lbx files in low case only. Else:

FILE* ../data/lbx/help.lbx (mode: rb) error: (2) No such file or directory
openmom: /home/rtentser/Sources/openmom/src/./platform/Path.h:84: bool file_handle::read(void *, size_t, size_t) const: Assertion `file' failed.
Aborted

And i think that getResourcePath change isn't permanent solution because it works only for me. Build/start from another directory will break the engine again.

[Jakz]

Most probably we should be fine in having a getResourcePath which returns "" and keep the executable in the same folder as data as it's usually done (or prefixed structure like ./bin/openmom`` and./data/`.

Regarding case sensitivity I didn't encounter the issue because I'm on a case insensitive file system. I'll try to enhance the loader to automatically check for both insensitive and sensitive file names.

If you are willing to help and you are not fluent with C++ there are some useful tasks (like populating yaml files) which doesn't require any programming skill at all (mostly).

[Jakz]

Ok I added a case insensitive find algorithm which uses to search for any file with same name regardless of case. I haven't been able to test in on unix though.

[Jakz]

I also enhanced the CMake script to build the executable directly in build directory (not in any subfolder) and to copy the data directory there.

So if everything works fine

mkdir build
cd build
cmake ..
make -j8
./openmom

Should work directly.

[rtentser]

If you are willing to help

I am, but i don't have much time now. If you have tasks for me, you can create an issue and assign me to it, and i'll try to solve them. Or you can write me in Telegram (same nickname).

which doesn't require any programming skill at all

I have some programming skills, but i'm not good in C/C++. I want to be better, if you have some simple C++ tasks, i'll try to solve them too.

[rtentser]

Should work directly.

Doesn't work for me. Right now the path sets to root directory, not to source directory as it should. You need to find a way to return it from getResourcePath (take it from cmake configs in build directory which can be easy to find because of relation with openmom file?). Or at least delete first '/' character from "/data/yaml/" in Path path = Platform::instance()->getResourcePath() + "/data/yaml/" + fileName; so the path will sets to a directory from which openmom started (so it can be started from source directory even if the build is elsewhere).

[Jakz]

maybe letting getResourcePath return "." should be enough. After running cmake you should have both openmom executable and data folder in the root of your build directory, if that's the case then yes, returning "." should be enough since you'd get ./data/yaml which should be fine.

[rtentser]

If data is in build directory, than yes, i think it should be enough.

[rtentser]

I've checked. Yes, it works. Thanks!