Open zaafonin opened 1 year ago
zaafonin
commented
1 year ago 0.5.0 produces a slightly different result:
Vsize: 24, 24
lib: /home/zaafonin/Downloads/Ninecraft/lib/x86/libminecraftpe.so: : 0x56742ce0
Ninecraft is running mcpe v0.5.0
4.6 (Compatibility Profile) Mesa 23.1.1
nine construct 0xd43bccc0
0xffdb46d0
debug: AppPlatform_linux::isPowerVR
debug: AppPlatform_linux::readAssetFile
Segmentation fault (core dumped), so something's definitely happening
zaafonin
commented
1 year ago Done a GDB on ninecraft executable:
which corresponds to
if (version_id >= version_id_0_6_0) {
default_mouse_mode = GLFW_CURSOR_HIDDEN;
}
glfwSetInputMode(_window, GLFW_CURSOR, default_mouse_mode);I've disabled the >0.6.0 check so the cursor mode is GLFW_CURSOR_NORMAL instead. That seemingly helps (also that's why 0.5.0 loads a bit further) because switching cursor mode to normal doesn't actually do anything when it's already normal, but the loading process still stops on:
, so it's not GLFW that is the problem. Everything boils down to
0xf786a725 in _XSend (dpy=0x5667ec50, data=0x0, size=0)
at /usr/src/debug/lib32-libx11/libX11-1.8.5/src/xcb_io.c:569
569 requests = dpy_request - dpy->xcb->last_flushed; Possible libX11 bug? Changing between native X11 and XWayland has no effect. Downgrading X11 a couple minor versions back doesn't help either.
EDIT: Downgrading lib32-libX11 to 1.7.0 pushes the loading process a bit further. Stack is corrupted, so can't provide a meaningful trace.
zaafonin
commented
1 year ago Attempted to swap the custom glfw for AUR's lib32-glfw-wayland. Surprisingly, a window actually does get initialized and loading gets quite far:
, line 1150 being just glfwSwapBuffers(_window); — will try to investigate more.
EDIT: Compiled bundled glfw with Wayland support and used glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_WAYLAND) in ninecraft's main.c to replicate the same effect, but with proven glfw: same segfault.
zaafonin
commented
1 year ago Commented out buffer swapping completely, and the game loads slightly further. On 0.6.1, sometimes (like 50% of times) the game crashes there:
No such behavior on 0.8.1. Now I certainly would be happy if the game worked with rendering enabled...
EDIT: This happened because lib32-systemd was installed which leads to to the gethostbyname segfault. This was only the case on 0.6.1 because this function is called almost immediately on start. On 0.8.1 it does happen, just later.
MFDGaming
commented
1 year ago You most likely don't have a 32bit video driver
zaafonin
commented
1 year ago Not the case. 32-bit Wine stuff wouldn't work either then.
zaafonin
commented
1 year ago Further observations.
1) The X11 segfault can be fixed by downgrading lib32-libx11 to 1.6.8 (gosh that's ancient)
2) Segfaulting in libglvnd:
Thread 1 "ninecraft" received signal SIGSEGV, Segmentation fault.
0xf799c311 in __glDispatchCheckMultithreaded () at ../libglvnd-v1.6.0/src/GLdispatch/GLdispatch.c:785
785 if (__glvndPthreadFuncs.equal(firstThreadId, GLVND_THREAD_NULL)) { can be fixed by compiling the master branch of libglvnd for x86 and LD_PRELOADing libGLdispatch.so. Probably will be the only solution until the fix lands into the 2023 release. After this, you will finally get to the main menu:
You will be able to navigate the menu freely, create a world, but half a second later you will be met with another segfault.
3) Next problem you'll encounter is a mystery segfault somewhere deep in amd drivers:
Thread 1 "ninecraft" received signal SIGSEGV, Segmentation fault.
0xf6d23620 in amdgpu_bo_va_op (bo=0x568ebb40, offset=0, size=2097152, addr=4303355904, flags=0, ops=2)
at ../libdrm-2.4.115/amdgpu/amdgpu_bo.c:754
Downloading source file /usr/src/debug/lib32-libdrm/build/../libdrm-2.4.115/amdgpu/amdgpu_bo.c
754 ../libdrm-2.4.115/amdgpu/amdgpu_bo.c: Directory not empty. (can also be "Bad file descriptor" or something else). Sometimes you will be able to avoid the segfault altogether (or rather skip to the next segfault), either by pure luck or by doing run in gdb after the segfault has happened, which restarts ninecraft. Again, I have no idea how or why this happens. This might be an AMD-exclusive problem.
Surprisingly, this problem disappears if you switch to Zink (can be done with MESA_LOADER_DRIVER_OVERRIDE=zink). However, on AMD you'll need to install lib32-amdvlk instead of lib32-vulkan-radeon. The importance of this will be explained further.
4) Next segfault happens in libXi, possibly because it isn't downgraded together with libx11:
Thread 1 "ninecraft" received signal SIGSEGV, Segmentation fault.
0xf77821f4 in XInputWireToCookie (dpy=0x56690c30, cookie=0x569962d4, event=0x56f5a5f0)
at /usr/src/debug/lib32-libxi/libXi-1.8.1/src/XExtInt.c:1007
1007 *cookie = *(XGenericEventCookie*)save; Unfortunately, Arch doesn't have libXi 1.6.8 in its repos anymore, so the downgrade isn't really possible. I took a radical approach and switched to Wayland (no matter how I dislike this thing). Despite GLFW_BUILD_WAYLAND already being used in the code, I couldn't force ninecraft to use it (even with glfwWindowHint(GLFW_PLATFORM, GLFW_PLATFORM_WAYLAND); for some reason).
What helped is screwing with CMakeLists.txt of the bundled glfw, specifically with lines 40 and 41:
cmake_dependent_option(GLFW_BUILD_X11 "Build support for X11" OFF "UNIX;NOT APPLE" OFF)
cmake_dependent_option(GLFW_BUILD_WAYLAND "Build support for Wayland" ON "UNIX;NOT APPLE" OFF)This is 100% bad code, but it does the job of forcing glfw (and ninecraft) to use Wayland. Finally the binary starts, the world loads and the game works.
lib32-amdvlk and other 32-bit libs:For Zink, it would be logical to use lib32-vulkan-radeon as it's pretty much the default choice for Vulkan drivers on AMD. However, this package depends on lib32-systemd among other stuff, and while I'm not a systemd hater by all means, mcpe on ninecraft surely is:
Thread 1 "ninecraft" received signal SIGSEGV, Segmentation fault.
0xd011e252 in stpcpy (__src=<optimized out>, __dest=<optimized out>, __dest=<optimized out>, __src=<optimized out>)
at /usr/include/bits/string_fortified.h:86
86 return __builtin___stpcpy_chk (__dest, __src, __glibc_objsize (__dest));Backtrace shows the culprit is libsystemd:
It looks like if lib32-systemd is installed, gethostbyname happens via libsystemd, where the segfault happens most probably because of a yet another ABI incompatibility. The only solution I've found is not having lib32-systemd in your system. lib32-amdvlk doesn't have it as a dependency, and that's why it's the best solution unless either the systemd dependency is circumvented or the underlying bug is fixed.
This problem is also present with lib32-pipewire and lib32-libpulse. For now I haven't found a way to use ninecraft with sound.
In conclusion, this problem looks like a whole can of worms resulting from the nonexistent culture of ABI compatibility in Linux systems. While the described manipulations worked on my machine, this might not be possible on systems without Vulkan, or Wayland or other stuff I don't know about. TL;DR: desktop Linux sucks
kran27
commented
7 months ago any chance you could provide your build? I tried getting it to compile following these instructions on my steam deck but ran into additional issues with linux headers and other stuff that I couldn't figure out.
Lassebq
commented
21 hours ago Hey guys, new crash just dropped:
#0 0x565bd2e6 in stbi.compute_huffman_codes ()
#1 0x565bdd55 in stbi.parse_zlib ()
#2 0x565c2678 in stbi.parse_png_file ()
#3 0x565cd048 in stbi.load_main ()
#4 0x565d0be4 in stbi.load_and_postprocess_8bit ()
#5 0x565d16ee in stbi_load ()
#6 0x56575637 in AppPlatform_linux$loadTexture ()
#7 0xde4f895f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)Happens on first loadTexture call with assets/particles.png
After installing all listed dependencies, compiling Ninecraft (with debug build type) and doing
extract.shon a x86 apk of 0.8.1, Ninecraft briefly shows a black window and segfaults:Fixing the audio (btw, I'd add
lib32-libpulseto readme as OpenAL still uses it) didn't change much except for the first line not being present, and the window showing up for just a little longer.Same thing happens with 0.7.6 and 0.6.1. Not familiar with MCPE internals atm, so can't figure out what might be wrong.