4.0 release 88 GNU/Linux segfaults on start

[GithubSuckBigTime]

Hello, congrats on the 4.0 release. I just wanted to try it out, downloaded the Linux 64bit build from itch.io but doing

./Mindustry

results in

Segmentation fault

Doing

java -jar desktop-release.jar

starts the game in a tutorial mode, but it behaves weird (e.g. the fog of war on the map stays the same).

Linux Mint 18.1 Serena
RELEASE=18.1
CODENAME=serena
EDITION="Cinnamon 64-bit"
DESCRIPTION="Linux Mint 18.1 Serena"
DESKTOP=Gnome
TOOLKIT=GTK
NEW_FEATURES_URL=http://www.linuxmint.com/rel_serena_cinnamon_whatsnew.php
RELEASE_NOTES_URL=http://www.linuxmint.com/rel_serena_cinnamon.php
USER_GUIDE_URL=help:linuxmint
GRUB_TITLE=Linux Mint 18.1 Cinnamon 64-bit
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

[Anuken]

There's nothing I can do with a Segmentation fault error message, sorry. It could be literally anything. Look for a JVM crash log of some sort.

[Anuken]

Note that I am using Mint 18.3, and the executable launches correctly for me.

[GithubSuckBigTime]

Yes, segfault is not very helpful, sorry. I'l try to find some logs and possibly also compile myself.

In the meantime I tried running it with valgrind. One time it crashed my desktop environment. Now it actually opened the window, but only black background with cursor. This is the output:

valgrind ./Mindustry
==7364== Memcheck, a memory error detector
==7364== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7364== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7364== Command: ./Mindustry
==7364== 
==7364== Warning: set address range perms: large range [0x86600000, 0x100000000) (noaccess)
==7364== Warning: set address range perms: large range [0x100000000, 0x140000000) (noaccess)
==7364== Invalid write of size 4
==7364==    at 0x82C4BE7: ???
==7364==    by 0x82B24E6: ???
==7364==    by 0x691FA3A: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x68D08A6: InstanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x68E0CA2: InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x68E0F60: InstanceKlass::initialize(Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x68E0E05: InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x68E0F60: InstanceKlass::initialize(Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x6CACF55: Threads::create_vm(JavaVMInitArgs*, bool*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x69309E3: JNI_CreateJavaVM (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x404931: std::_Function_handler<void* (void*), launchJavaVM::{lambda(void*)#1}>::_M_invoke(std::_Any_data const&, void*&&) (in /home/tastyfish/Games/mindustry 4/Mindustry)
==7364==    by 0x40A7F6: std::_Function_handler<void (std::function<void* (void*)>, JavaVMInitArgs const&), main::{lambda(std::function<void* (void*)>, JavaVMInitArgs const&)#1}>::_M_invoke(std::_Any_data const&, std::function<void* (void*)>&&, JavaVMInitArgs const&) (in /home/tastyfish/Games/mindustry 4/Mindustry)
==7364==  Address 0xffeffd6a0 is on thread 1's stack
==7364==  4096 bytes below stack pointer

...

==7364== Invalid write of size 4
==7364==    at 0x82C4BE7: ???
==7364==    by 0x83DB8D3: ???
==7364==    by 0x82B9D7F: ???
==7364==    by 0x82B9D7F: ???
==7364==    by 0x82B24E6: ???
==7364==    by 0x691FA3A: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x6982708: JVM_DoPrivileged (in /home/tastyfish/Games/mindustry 4/jre/lib/amd64/server/libjvm.so)
==7364==    by 0x82C9773: ???
==7364==    by 0x82B9D7F: ???
==7364==    by 0x82B9D7F: ???
==7364==    by 0x82B9D7F: ???
==7364==    by 0x82B24E6: ???
==7364==  Address 0xffeff89c8 is on thread 1's stack
==7364==  4096 bytes below stack pointer
==7364== 
==7364== 
==7364== More than 1000 different errors detected.  I'm not reporting any more.
==7364== Final error counts will be inaccurate.  Go fix your program!
==7364== Rerun with --error-limit=no to disable this cutoff.  Note
==7364== that errors may occur in your program without prior warning from
==7364== Valgrind, because errors are no longer being displayed.
==7364== 
==7383== Warning: invalid file descriptor 1024 in syscall close()
==7383== Warning: invalid file descriptor 1025 in syscall close()
==7383== Warning: invalid file descriptor 1026 in syscall close()
==7383== Warning: invalid file descriptor 1027 in syscall close()
==7383==    Use --log-fd=<number> to select an alternative log fd.
==7383== Warning: invalid file descriptor 1028 in syscall close()
==7383== Warning: invalid file descriptor 1029 in syscall close()
--- CONTENT INFO ---
[item]: loaded 16
[block]: loaded 279
[mech]: loaded 8
[bullet]: loaded 51
[liquid]: loaded 4
[status]: loaded 11
[unit]: loaded 15
[weather]: loaded 0
[effect]: loaded 0
[zone]: loaded 12
[loadout]: loaded 4
[typeid]: loaded 18
Total content loaded: 418
-------------------
Time to generate menu: 4439.985
Time to load [total]: 120508.37
==7364== 
==7364== HEAP SUMMARY:
==7364==     in use at exit: 58,206,096 bytes in 61,110 blocks
==7364==   total heap usage: 246,264 allocs, 185,154 frees, 2,748,985,638 bytes allocated
==7364== 
==7364== LEAK SUMMARY:
==7364==    definitely lost: 4,332 bytes in 44 blocks
==7364==    indirectly lost: 38,712 bytes in 51 blocks
==7364==      possibly lost: 5,570,518 bytes in 344 blocks
==7364==    still reachable: 52,592,534 bytes in 60,671 blocks
==7364==                       of which reachable via heuristic:
==7364==                         newarray           : 22,536 bytes in 1 blocks
==7364==         suppressed: 0 bytes in 0 blocks
==7364== Rerun with --leak-check=full to see details of leaked memory
==7364== 
==7364== For counts of detected and suppressed errors, rerun with: -v
==7364== Use --track-origins=yes to see where uninitialised values come from
==7364== ERROR SUMMARY: 1314685 errors from 1000 contexts (suppressed: 0 from 0)

[skybldev]

I don't know if this helps, but maybe your RAM is aging? I had segfaults and other memory related problems at random on any software on my old HP Pavillion DV6 about 3 years ago. Your JVM isn't the problem, nor is the software, and that can be proven because it works on basically everyone elses' machines. It's also a sure fire sign that that is the case when Java suddenly produces 1000+ error messages on an otherwise fine working software.

If you have to reboot your computer one time, I suggest you run memtest86 which is a boot choice if you are using GRUB.

[GithubSuckBigTime]

I don't think it's hardware, everything else runs fine, it's exactly only this binary and it fails always. It may be an error on my side, maybe some out of date package or wrong configuration of something. The 1000+ errors are given by valgrind, not Java, and it's pretty common to see this if the error happens in a loop. It seems to be happening in that java binary library distributed with the game.

[GithubSuckBigTime]

Actually wait, if I just run the jar like

java -jar desktop-release.jar

I can quit to menu and then the game seems like it's working. Is this a valid way of starting the game? I also tried to build the game according to instruction in the README and that way it behaves the same.

If I start the first mission, I can move without colliding with anything -- is it supposed to be like this?

If that is all okay, then it is only the Mindustry binary that is segfaulting then. How can I rebuild that one?

[skybldev]

Yes, the java -jar is the correct way. And yes, you can go through walls if you are a flying mech.

[Anuken]

The binary was obtained by using packr. I believe they have it pre-built somewhere.

[Anuken]

Looking at the issues, it looks like it might be time for me to transition to another packing tool. It seems that the repository is more or less dead; no significant changes have been made in months.

[GithubSuckBigTime]

It looks like its the packr then. I can now play the game, which is great, thanks for assistance. If you want to test linux binaries with new packing tools, drop them here and I can try to run them.

[Kieaer]

Can't reproduce from Ubuntu 19.04 :eyes:

[Anuken]

@GithubSuckBigTime How about this: Delete the Mindustry executable, and replace it with a file named Mindustry.sh with the following contents:

chmod +x jre/bin/java
jre/bin/java -jar desktop-release.jar

The, apply executable permissions to the Mindustry.sh (chmod +x Mindustry.sh) and run it. Does that work?

[GithubSuckBigTime]

No, it killed my window manager :P But this works:

#!/bin/bash
java -jar desktop-release.jar

I think the problem is with the binary distribution of Java there (in the jre folder), as it works with Java I installed normally via my package manager.

[Anuken]

I've investigated some other options and none of them work as well as packr does for my use case. Additionally, this issue seems very PC specific, as nobody else has reported any similar issues and events like killed my window manager really don't seem like signs of a well functioning OS. Unless this becomes a widespread issue, I won't be fixing it.