Hello,

After having successfully run Toki Tori 2+ on Windows 10 (64 bits) several times, I have tried running it on GNU/Linux and it ends in a crash. I got the following stack trace:
#0 0x00007ffff66ea765 in raise () from /lib64/libc.so.6
#1 0x00007ffff66ebc78 in abort () from /lib64/libc.so.6
#2 0x00007ffff6fd996d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#3 0x00007ffff6fd7a66 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#4 0x00007ffff6fd7a93 in std::terminate() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#5 0x00007ffff6fd7cbe in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#6 0x00007ffff6fd81ad in operator new(unsigned long) () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#7 0x00007ffff6fd8249 in operator new[](unsigned long) () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#8 0x00000000007adadb in toki::game::script::Registry::load(std::map<std::string, tt::script::ScriptValue, std::less<std::string>, std::allocator<std::pair<std::string const, tt::script::ScriptValue> > >&, std::tr1::shared_ptr<tt::fs::File> const&) ()
#9 0x000000000087395a in toki::serialization::loadShutdownState(unsigned int*, bool) ()
#10 0x000000000084934f in toki::main::loadstate::LoadStateGame::doLoadStep() ()
#11 0x0000000000840c81 in toki::main::StateLoadApp::loadThread() ()
#12 0x00007ffff7792f73 in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff67a1dfd in clone () from /lib64/libc.so.6

Here is the disassembling of frame #6 (the apparent location of the actual crash):
0x00007ffff6fd8130 <+0>: push %rbp
0x00007ffff6fd8131 <+1>: mov $0x1,%eax
0x00007ffff6fd8136 <+6>: push %rbx
0x00007ffff6fd8137 <+7>: mov %rdi,%rbx
0x00007ffff6fd813a <+10>: sub $0x8,%rsp
0x00007ffff6fd813e <+14>: test %rdi,%rdi
0x00007ffff6fd8141 <+17>: cmove %rax,%rbx
0x00007ffff6fd8145 <+21>: mov %rbx,%rdi
0x00007ffff6fd8148 <+24>: callq 0x7ffff6fd2570 <malloc@plt>
0x00007ffff6fd814d <+29>: test %rax,%rax
0x00007ffff6fd8150 <+32>: jne 0x7ffff6fd8178 <_Znwm+72>
0x00007ffff6fd8152 <+34>: mov 0x28b9df(%rip),%rbp # 0x7ffff7263b38
0x00007ffff6fd8159 <+41>: nopl 0x0(%rax)
0x00007ffff6fd8160 <+48>: mov 0x0(%rbp),%rax
0x00007ffff6fd8164 <+52>: test %rax,%rax
0x00007ffff6fd8167 <+55>: je 0x7ffff6fd817f <_Znwm+79>
0x00007ffff6fd8169 <+57>: callq *%rax
0x00007ffff6fd816b <+59>: mov %rbx,%rdi
0x00007ffff6fd816e <+62>: callq 0x7ffff6fd2570 <malloc@plt>
0x00007ffff6fd8173 <+67>: test %rax,%rax
0x00007ffff6fd8176 <+70>: je 0x7ffff6fd8160 <_Znwm+48>
0x00007ffff6fd8178 <+72>: add $0x8,%rsp
0x00007ffff6fd817c <+76>: pop %rbx
0x00007ffff6fd817d <+77>: pop %rbp
0x00007ffff6fd817e <+78>: retq
0x00007ffff6fd817f <+79>: mov $0x8,%edi
0x00007ffff6fd8184 <+84>: callq 0x7ffff6fd2d90 <__cxa_allocate_exception@plt>
0x00007ffff6fd8189 <+89>: mov 0x28b838(%rip),%rdx # 0x7ffff72639c8
0x00007ffff6fd8190 <+96>: mov 0x28b4b9(%rip),%rsi # 0x7ffff7263650
0x00007ffff6fd8197 <+103>: mov %rax,%rdi
0x00007ffff6fd819a <+106>: add $0x10,%rdx
0x00007ffff6fd819e <+110>: mov %rdx,(%rax)
0x00007ffff6fd81a1 <+113>: mov 0x28bd48(%rip),%rdx # 0x7ffff7263ef0
0x00007ffff6fd81a8 <+120>: callq 0x7ffff6fd3240 <__cxa_throw@plt>
=> 0x00007ffff6fd81ad <+125>: cmp $0xffffffffffffffff,%rdx
0x00007ffff6fd81b1 <+129>: mov %rax,%rdi
0x00007ffff6fd81b4 <+132>: je 0x7ffff6fd81bb <_Znwm+139>
0x00007ffff6fd81b6 <+134>: callq 0x7ffff6fd43d0 <_Unwind_Resume@plt>
0x00007ffff6fd81bb <+139>: callq 0x7ffff6fd2a20 <__cxa_call_unexpected@plt>

__cxa_throw is called at offset +120, which is branched from offset +55, which is ultimately caused by the 64-bits integer pointed by rbp being 0, which I guess is the first parameter, the size given to operators new and new[], provided by the size of an array given by toki::game::script::Registry::load . So I guess something bad happened while loading the "registry" (whatever it could be on GNU/Linux). I can check the registry if needed (that is if someone tells me where it is). I can also provide a coredump if needed.