Cannot move after a few seconds (OS X, brew)

[brabalan]

After a few seconds, I can no longer move nor jump. I can still look around using the mouse, and the game has not crashed.

I'm using OS X El Capitan, and I installed the current version of Minetest with Homebrew. I tried to set the debug level to 4 but I cannot see anything strange in the debug file.

I also reported this on the forums, and others said they can reproduce it: https://forum.minetest.net/viewtopic.php?f=6&t=15057

[Wayward1]

I believe I have encountered this as well (or at least something similar), quite a few times. Random servers, random times, when I join I can look around but not move. A simple relog fixes the problem, for me at least.
Linux Mint 17.3

[brabalan]

Unfortunately relogging fixes the problem, but only for a few seconds.

[echosa]

I'm having this issue as well. I mentioned it here: #2697 (comment)

[echosa]

This issue keeps Minetest from being playable on Mac. I've switched to the minimal dev game, turned off all the main options on the Settings page like shaders, smooth lighting, etc. I turned the logging level to verbose. I still have this issue and see nothing in the logs. When I run the game from the command line with --info --verbose, I don't see anything useful either. I have no idea what's causing this issue, but I also don't have any idea how to start trying to find out. Are there any other logs that are kept? Is there any other way to figure out what's going on? I've been able to play a bit on Windows 10, once I got it working there, and I enjoy the game. Not being able to play on OS X, though, is very unfortunate, as I'm rarely logged into Windows.

[brabalan]

I gave the nightly from https://github.com/krondor-game/minetest/releases a try and it works great. As the issue also arises from the stable version from there, I assume it has been fixed in the intervening commits, and homebrew will start working again when a new version is out. In the meantime I recommend using the nightly build.

[echosa]

@brabalan Oh, cool. I'll give that a shot when I get a chance!

[echosa]

Interesting... when I use the krondor-game version, the games seems to run fine. (Which is awesome!) However, when I install through homebrew, even if I install the latest code with brew install minetest --HEAD, I still have the problem.

So, what's different about krondor-game's version that makes it work? Or, rather, what's different about the brew built version that makes it not work?

[echosa]

I've asked about this on the forum page for the krondor releases: https://forum.minetest.net/viewtopic.php?f=42&t=9190&p=234545#p234545

[neoascetic]

Reproducible even for Krondor's nightly (i. e. latest) builds. Bad. It means we don't have the freshest playable version of minetest for OSX now.

[neoascetic]

Okay, I've found something. The latest playable version I have under my hand was built under OSX10.9. And the latest available (and thus unplayable) version was built under OSX10.11. This explains why we have the issue when building using homebrew (I guess most users has Sierra or at least El Capitan installed). Thus, this looks like some OS-related issue and we need to dig in that direction. Also, Irrlicht was updated from 1.8.3 to 1.8.4, need to check as well.

[echosa]

I can confirm I've been using El Capitan the whole time.

[brabalan]

Same here, using El Capitan.

[neoascetic]

Is there someone with 10.9 to test if it's OSX's issue or Irrlicht's?

[neoascetic]

Even if there are no blocks under the character it does not fall. It means that this is actually player's physics simulation problem and not something related to keyboard input. Appears in singleplayer as well.

[echosa]

I do not have access to any OS X prior to El Capitan. Maybe a VM would suffice, though?

[ghost]

Also note that fast_move seems to not work. I think that might be a config issue though.

[nigels-com]

Same problem here on Mac 10.12.2 (Sierra) and brew minetest 0.4.14. Some keys work, such as digging blocks, including those below the player.

[kencu]

For a data point, I just built minetest 0.4.14 using macports and irrlicht 1.8.4 on MacOS 10.6, and it also has the 'no movement' after a few moments use issue. No error messages so far to give a clue as to why. Some keys still work, but not w/a/s/d. Will see if I can help figure out what's going on.

[kencu]

Changing the build type to RelWithDebInfo instead of Release seems to fix the movement problem, at least on the Macports version I'm working on. This is on 10.6, and also on 10.12. Setting build type to Debug fixed it too, but with some extra detail left on the screen. MinSizeRel also seems to work correctly...

Actually, in the src/CMakeLists.txt file, it gives a list of build type options
Choose the type of build. Options are: None Debug SemiDebug RelWithDebInfo MinSizeRel
and the standard Release is not one of them.

[nigels-com]

Might be worth valgrinding minetest on Linux, to see how healthy things are in terms of unintialised memory reads. (UMR)

[scfarley]

I am also experiencing this with FreeBSD 11.0-STABLE (r310303). I did not see it with FreeBSD 10-STABLE (at least 10.3). I turned off all the port options without any luck.

However, I was successful when compiling with gcc v6 instead of clang (3.8 or 3.9). It could be a bug with clang, or there is a bug in the minetest code that is only noticeable when built by clang. This is presuming that macports uses clang.

[kencu]

macports with clang appears to work great with any target other than "Release".

[nigels-com]

I was hoping to reproduce this on Ubuntu 16.04 with clang/clang++ toolchain, but no luck. Valgrind seems clean, overall.

[neoascetic]

I can confirm that this doesn't happen in Debug build type. I'll switch krondor-game releases to this type for now, but I hope someone will find the real cause of the problem.

[kencu]

@nigels-com
We also have valgrind on macports, but I don't have much experience using it. If you give me a couple of pointers on how to get started with using it to examine minetest, I'll see what it comes up.

It sounds very much like clang's optimizations are bringing in this problem... don't know how else to explain it at the moment.

[echosa]

Can that same patch (or similar) be added the the homebrew forumula?

[kencu]

I'm not sure how to do that (I should learn more about homebrew, seems like a lot of nice people there) -- but the fix itself, assuming it works as well for others as it does here on this system, is quite a simple one -- just delete that one optimization flag from src/CMakeLists.txt.

[nigels-com]

I'm no Ruby wizard, but I'm poking about in the brew formula. brew edit minetest . It has two modes: stable (which I'm updating from 0.4.14 to 0.4.15) and head which appears to be from github master branch. Ideally the CMakeLists.txt would support a flag for opting in our out of --ffast-math.

$ brew upgrade minetest
==> Upgrading 1 outdated package, with result:
homebrew/games/minetest 0.4.15
==> Upgrading homebrew/games/minetest 
==> Downloading https://github.com/minetest/minetest/archive/0.4.15.tar.gz
==> Downloading from https://codeload.github.com/minetest/minetest/tar.gz/0.4.15
######################################################################## 100.0%
==> Downloading https://github.com/minetest/minetest_game/archive/0.4.15.tar.gz
==> Downloading from https://codeload.github.com/minetest/minetest_game/tar.gz/0.4.15
######################################################################## 100.0%
==> cmake . -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/minetest/0.4.15 -DCMAK
==> make package
==> unzip minetest-*-osx.zip
==> Caveats
...
==> Summary
🍺  /usr/local/Cellar/minetest/0.4.15: 944 files, 33.6M, built in 2 minutes 53 seconds

[nigels-com]

Brew master branch build using --HEAD:

$ brew install --HEAD minetest
==> Installing minetest from homebrew/games
==> Cloning https://github.com/minetest/minetest.git
Cloning into '/Users/nigels/Library/Caches/Homebrew/minetest--git'...
remote: Counting objects: 1033, done.
remote: Compressing objects: 100% (913/913), done.
remote: Total 1033 (delta 128), reused 524 (delta 63), pack-reused 0
Receiving objects: 100% (1033/1033), 8.47 MiB | 1.64 MiB/s, done.
Resolving deltas: 100% (128/128), done.
==> Checking out branch master
==> Cloning https://github.com/minetest/minetest_game.git
Cloning into '/Users/nigels/Library/Caches/Homebrew/minetest--minetest_game--git'...
remote: Counting objects: 640, done.
remote: Compressing objects: 100% (579/579), done.
remote: Total 640 (delta 69), reused 527 (delta 47), pack-reused 0
Receiving objects: 100% (640/640), 1.36 MiB | 320.00 KiB/s, done.
Resolving deltas: 100% (69/69), done.
==> Checking out branch master
==> cmake . -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/minetest/HEAD-a95f983 
==> make package
...

[nigels-com]

I filed a pull request for homebrew-games minetest formula:
https://github.com/Homebrew/homebrew-games/pull/757

The fix removes the -ffast-math flag in the CMakeLists.txt

[scfarley]

Removing -ffast-math from the release build fixes minetest when built with Clang v3.8 on FreeBSD. I have opened a bug with a fix for FreeBSD ports: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215532

[neoascetic]

Actually, the issue appears even with GCC, so it isn't only Clang's issue.

[neoascetic]

Should -ffast-math be disabled within the minetest repo for OSX and FreeBSD instead?

[nigels-com]

We think it's clang-specific. I'll go try repo it with gcc (assuming there is a brew gcc I can bring to the Mac). I guess so far the logic would be to omit -ffast-math for both Mac and FreeBSD. Or enable it only for Linux, perhaps.

[neoascetic]

It isn't clang-specific on OSX.

[nigels-com]

@neoascetic Do you have any suggestions for gcc toolchain on Sierra? brew gcc-6 seemed to choke on CoreFoundation headers.

[neoascetic]

My bad, I was building minetest on travis and it seems that you need more steps than just specify compiler: gcc in the .travis.yml.

Anyway, I was unable to build minetest with GCC because of all those error: 'introduced' was not declared in this scope errors (see log here).

So, maybe it is clang-specific issue after all.

[nigels-com]

The brew patch has been accepted and merged.
Works for me on Sierra.

$ brew uninstall minetest
Uninstalling /usr/local/Cellar/minetest/0.4.15... (944 files, 33.6M)
$ brew install minetest
==> Installing minetest from homebrew/games
==> Downloading https://homebrew.bintray.com/bottles-games/minetest-0.4.15.sierra.bottle.tar.gz
######################################################################## 100.0%
==> Pouring minetest-0.4.15.sierra.bottle.tar.gz
==> Caveats
...
==> Summary
🍺  /usr/local/Cellar/minetest/0.4.15: 944 files, 33.6M
$

The logic I'd suggest for Minetest CMakeLists.txt would be to make -ffast-math an opt-in.

[kencu]

You could also add the --fast-math flag only if the compiler is gcc. Cmake can do this pretty easily.

[nigels-com]

It would need some testing. Out of the box clang pretends to be gcc, so we'd want to be sure that cmake is sure that it really is gcc, and not just a pretender.

[sfan5]

clang with -ffast-math works fine on Linux, so always disabling it isn't a solution.

[kencu]

hey, that's interesting. clang with fast-math fails on MacOS and FreeBSD (apparently) but works on Linux... curious. You would think the fast-math macros would work the same on all three platforms...

[nigels-com]

Possibly concerning sqrt
https://llvm.org/bugs/show_bug.cgi?id=24063

[Zeno-]

One of the things that fast-math (in addition to what nigels-com pointed out) can do that will not happen (ever) on floating point expressions is re-arrange or simplify them. This would normally just potentially introduce precision errors (and why without fast-math the compiler will never re-arrange floating point operations[1]). That in itself seems to be unlikely to cause a crash, but it's possible.

[1] I think the C++ Standard actually says that the compiler is not allowed to without the user expressly telling it to using e.g. a switch like fast-math

[Thomas--S]

I installed minetest with homebrew on my MacBook again today, and I can confirm that the problem seems to be fixed.

[brabalan]

Everything is now working, so I'm closing the issue.

[vlapsley]

The issue is fixed using Homebrew, but the bug remains when compiling from source.

[neoascetic]

@vlapsley exactly, because Homebrew's formula patches build instructions in order to avoid the bug. IMO the bug wasn't fixed, that was just a workaround.

[nigels-com]

Yes, confirming the issue is still there for a vanilla cmake build from master branch.
The brew installed minetest is fine.