[linux] Crash when start new game #387
Comments
|
Are you using the Flatpak version of TFE, and the Snap version of Steam by any chance? |
|
I'm experiencing what appears to be the same crash: No Flatpaks or Snaps involved, just the AUR package on Arch. I had installed it previously without issue, but after recompiling today it doesn't work. |
|
I'm also pulling from the AUR. Though after a bunch of system packages updates yesterday its now saying it cant find the midi so. I'm thinking its a Manjaro thing :( |
|
I'm having the same issue as OP. I'm using endeavor OS though @tanuki2k so I'm pretty sure this is probably an arch thing? It happens with the flatpak, the AUR and from binaries that I compiled myself. Here is the error it throws when launching it from console: [juancm@Durandal ~]$ theforceengine [Paths] Program Path: "/home/juancm/" |
|
The current public Flatpak build works fine here on SteamOS (being an Arch fork also). As I'm on a Steam Deck I can't install the AUR package to try... however 1.9.530 is the previous release. Is the binary you've built yourself 1.9.540? |
|
the flatpak didnt work for me on Manjaro. |
The self compiled binary is v1.09.540-266-g2fe1506a. So something weird happened. For unrelated reasons I decided to make a clean install of my system. After that I self compiled the binary again ( I was wondering if now that I have a clean install if it would make a difference) and IT WORKS! I'm not really sure why it works now, as it is basically the same system config and packages as old install but I'm not complaining. |
|
I was able to get it working by downloading and building the 1.09.540 source code from github, rather then using the AUR version, but only if I run it from the terminal. it crashes when I start new game if I run it from the desktrop icon. |
|
I have the same crash with flatpak 1.09.540+ on Linux Mint 21.3, here is my error log (hope it helps) [Main] The Force Engine v1.09.540+ |
|
I am experiencing an immediate crash since the latest No matter what I try to launch, be it a new game, a mod, or load a saved game, it always crashes with the same back trace, including when using the However, using the Mesa 3D software renderer with |
😢 Continues to crash. Things got even worse. Now, TFE crashes on exit too: |
|
@JakeSmarter: If you apply this patch, does it make more progress? Which GPU do you have on our ARM64? index 8722179d..c4022ea2 100644
--- a/TheForceEngine/TFE_RenderBackend/Win32OpenGL/textureGpu.cpp
+++ b/TheForceEngine/TFE_RenderBackend/Win32OpenGL/textureGpu.cpp
@@ -52,7 +52,7 @@ bool TextureGpu::create(u32 width, u32 height, TexFormat format, bool hasMipmaps
// Catch a case where a pre-existing error is causing failures.
GLenum error = glGetError();
- assert(error == GL_NO_ERROR);
+// assert(error == GL_NO_ERROR);
if (error != GL_NO_ERROR)
{
TFE_System::logWrite(LOG_WARNING, "TextureGPU - OpenGL", "Pre-existing OpenGL error: 0x%x when calling TextureGpu::create().", error);
@@ -70,7 +70,7 @@ bool TextureGpu::create(u32 width, u32 height, TexFormat format, bool hasMipmaps
glTexImage2D(GL_TEXTURE_2D, 0, c_internalFormat[format], width, height, 0, c_baseFormat[format], GL_HALF_FLOAT, nullptr);
error = glGetError();
}
- assert(error == GL_NO_ERROR);
+// assert(error == GL_NO_ERROR);
if (error != GL_NO_ERROR)
{
TFE_System::logWrite(LOG_ERROR, "TextureGPU - OpenGL", "Failed to create texture - size: (%u, %u), format: %s. Error ID: 0x%x",
@@ -120,7 +120,7 @@ bool TextureGpu::createArray(u32 width, u32 height, u32 layers, u32 channels, u3
}
width >>= 1;
height >>= 1;
- assert(glGetError() == GL_NO_ERROR);
+// assert(glGetError() == GL_NO_ERROR);
}
glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
@@ -130,7 +130,7 @@ bool TextureGpu::createArray(u32 width, u32 height, u32 layers, u32 channels, u3
glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);
glBindTexture(GL_TEXTURE_2D_ARRAY, 0);
- assert(glGetError() == GL_NO_ERROR);
+// assert(glGetError() == GL_NO_ERROR);
return true;
}
@@ -185,7 +185,7 @@ bool TextureGpu::update(const void* buffer, size_t size, s32 layer, s32 mipLevel
glBindTexture(GL_TEXTURE_2D_ARRAY, 0);
}
- assert(glGetError() == GL_NO_ERROR);
+// assert(glGetError() == GL_NO_ERROR);
return true;
}
|
|
FYI, I am running on the “Broadcom V3D 4.2.12” OpenGL renderer (or Broadcom VideoCore 6 GPU), aka the Raspberry Pi 4B GPU. Thread 1 "theforceengine" received signal SIGABRT, Aborted.
0x0000fffff77a6a00 in __pthread_kill_implementation () from /usr/lib/aarch64-linux-gnu/libc.so.6
(gdb) bt
#0 0x0000fffff77a6a00 in __pthread_kill_implementation () from /usr/lib/aarch64-linux-gnu/libc.so.6
#1 0x0000fffff775fc6c in raise () from /usr/lib/aarch64-linux-gnu/libc.so.6
#2 0x0000fffff774ad3c in abort () from /usr/lib/aarch64-linux-gnu/libc.so.6
#3 0x0000fffff77593a0 in __assert_fail_base () from /usr/lib/aarch64-linux-gnu/libc.so.6
#4 0x0000fffff7759410 in __assert_fail () from /usr/lib/aarch64-linux-gnu/libc.so.6
#5 0x0000aaaaaabf1720 in TextureGpu::create (this=this@entry=0xaaaaabd3e190, width=width@entry=426, height=height@entry=240, format=format@entry=TEX_RGBA8, hasMipmaps=hasMipmaps@entry=false, magFilter=magFilter@entry=MAG_FILTER_NONE)
at /run/build/tfe/TheForceEngine/TFE_RenderBackend/Win32OpenGL/textureGpu.cpp:53
#6 0x0000aaaaaabed058 in TFE_RenderBackend::createTexture (width=width@entry=426, height=height@entry=240, format=format@entry=TEX_RGBA8) at /run/build/tfe/TheForceEngine/TFE_RenderBackend/Win32OpenGL/renderBackend.cpp:802
#7 0x0000aaaaaab60b58 in TFE_FrontEndUI::configSaveLoadBegin (save=save@entry=false) at /run/build/tfe/TheForceEngine/TFE_FrontEndUI/frontEndUi.cpp:1564
#8 0x0000aaaaaab60f68 in TFE_FrontEndUI::saveLoadDialog (save=save@entry=false) at /run/build/tfe/TheForceEngine/TFE_FrontEndUI/frontEndUi.cpp:1587
#9 0x0000aaaaaab614e0 in TFE_FrontEndUI::configLoad () at /run/build/tfe/TheForceEngine/TFE_FrontEndUI/frontEndUi.cpp:1808
#10 0x0000aaaaaab64044 in TFE_FrontEndUI::draw (drawFrontEnd=<optimized out>, noGameData=<optimized out>, setDefaults=<optimized out>, showFps=showFps@entry=false) at /run/build/tfe/TheForceEngine/TFE_FrontEndUI/frontEndUi.cpp:933
#11 0x0000aaaaaac5910c in main (argc=1, argv=0xffffffffebd8) at /run/build/tfe/TheForceEngine/main.cpp:875Indeed, it crashes, or rather aborts, on the --- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -23,6 +23,7 @@ set(CMAKE_CXX_EXTENSIONS OFF)
## when not debugging to not hide any real bugs).
if(CMAKE_BUILD_TYPE STREQUAL "Release")
check_cxx_compiler_flag("-ftrivial-auto-var-init=zero" COMPILER_ENABLE_AUTOZERO)
+ add_compile_definitions(NDEBUG)
endif()
if (UNIX AND NOT APPLE)However, the app crashes on returning to the main menu: Thread 1 "theforceengine" received signal SIGSEGV, Segmentation fault.
0x0000aaaaaaae0980 in TFE_Sprite_Jedi::freePool (pool=pool@entry=POOL_GAME) at /run/build/tfe/TheForceEngine/TFE_Asset/spriteAsset_Jedi.cpp:717
(gdb) bt
#0 0x0000aaaaaaae0980 in TFE_Sprite_Jedi::freePool (pool=pool@entry=POOL_GAME) at /run/build/tfe/TheForceEngine/TFE_Asset/spriteAsset_Jedi.cpp:717
#1 0x0000aaaaaaae0a08 in TFE_Sprite_Jedi::freeAll () at /run/build/tfe/TheForceEngine/TFE_Asset/spriteAsset_Jedi.cpp:731
#2 0x0000aaaaaab26e80 in TFE_DarkForces::DarkForces::exitGame (this=<optimized out>) at /run/build/tfe/TheForceEngine/TFE_DarkForces/darkForcesMain.cpp:376
#3 0x0000aaaaaab68f6c in freeGame (game=0xaaaaac213570) at /run/build/tfe/TheForceEngine/TFE_Game/igame.cpp:82
#4 0x0000aaaaaac4ed00 in main (argc=1, argv=0xffffffffebb8) at /run/build/tfe/TheForceEngine/main.cpp:741 |
Did you catcht the error code returned by glGetError()?
i'm on the fence about this. it did catch something unexpected (i.e. your particular gl setup),
See #407 to fix that. |
Right, now that the
I have not tried the #407 fix yet but may give a try should I have more time. |
Do you want to try something? I've implemented a rudimentary version of the gl debug callback. with mesa it prints something like this: Thanks! |
Thanks, I’ll give it a shot sometime.
Nice, I have not tried it with Mesa 3D’s software renderer. So, there is a GL error after all. One more thing; when using |
Interesting, Mesa 3D’s software renderer does not log a GL error in |
Well, I think you need to sprinkle the code with glGetError() calls to find out what V3D doesn't like |
Yeah, V3D on VideoCore 6 does not support OpenGL 4.3. However, it supports the |
|
@mlauss2 I have tested your I am not sure where that |
Thanks for testing! Yeah, radeonsi on my system also spits out stats from the shader compiler via this debug.
entry "007" is the faulting one, can you please paste the output of Thanks! |
|
Eh, the abort is due to the "Critical" in "[Critical : GPU] Cannot initialize GPU/Window." |
|
Hello All, at the root of the source directory, build with: at the gdb prompt type "r" to run it, then set it to "windowed" mode so you can see the console window. Thanks! |
|
For context when compiling on Windows assert() is compiled out for RELEASE builds (which is what gets distributed). The asserts are meant for development using a debugger, not for end-users to trigger. The asserts can just be compiled out for the Linux build. In terms of the actual issue, though, TFE currently requires a minimum set OpenGL features, set for the GPU renderer. In the future the plan is to support software rendering for imGUI and remove that restriction for the software renderer. However, most systems that fall into this category will likely not run well since TFE was designed for semi-modern systems. That said, the asserts on Linux active even in Release style builds is an issue. |
I think that Visual Studio, including the Code edition, by default defines the |
|
with the default build instructions, cmake does add the -DNDEBUG and there are no assert()s left. vs. The original issue looks like a member of null-pointered struct being accessed: |
$ cmake --version
cmake version 3.29.6
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ cmake --system-information | grep -F NDEBUG
CMAKE_CXX_FLAGS_MINSIZEREL == "-Os -DNDEBUG"
CMAKE_CXX_FLAGS_RELEASE == "-O3 -DNDEBUG"
CMAKE_CXX_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG"
CMAKE_C_FLAGS_MINSIZEREL == "-Os -DNDEBUG"
CMAKE_C_FLAGS_RELEASE == "-O3 -DNDEBUG"
CMAKE_C_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG"
CMAKE_CXX_FLAGS_MINSIZEREL "-Os -DNDEBUG"
CMAKE_CXX_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG"
CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG"
CMAKE_CXX_FLAGS_RELEASE_INIT " -O3 -DNDEBUG"
CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g -DNDEBUG"
CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG"
CMAKE_C_FLAGS_MINSIZEREL "-Os -DNDEBUG"
CMAKE_C_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG"
CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG"
CMAKE_C_FLAGS_RELEASE_INIT " -O3 -DNDEBUG"
CMAKE_C_FLAGS_RELWITHDEBINFO "-O2 -g -DNDEBUG"
CMAKE_C_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG"You are right. 👍 Good to have this clarified. Then there must be something funny going on with the Flatpak build manifest. |
Let's get @fpiesche in here too, maybe he can solve this and get the flatpak built with "-DCMAKE_BUILD_TYPE=RelWithDebInfo" |
|
I'll give that a go when I have a chance; need to update for the new release anyway :) The general guideline with Flatpaks is to make a debug build as the build infra will then strip the debug information and extract it into a separately-available debug package so debug symbols etc for any specific release can be easily installed when a developer wants/needs them but aren't deployed to normal users' machines, so I'd stuck with this - one of Flathub's reviewers previously in fact specifically asked me not to strip binaries but if unstripped builds are causing problems here then obviously making a RelWithDebInfo build should probably do the trick. |
|
My two cents to this is that I have mixed feelings about
Just to clarify; stripped or not, debug symbols or not, the issue here is that |
It's still reasonably accurate to work with and experienced users can then attach gdb to get a good backtrace or run addr2line to report the crashing source line. |
|
Good to know the assert issue is due to the Flatpak build - that makes a lot more sense. |
|
Maybe I am exaggerating this but GCC’s section 3.10 Options for Debugging Your Program of the manual says:
However, section 3.11 Options That Control Optimization says:
@fpiesche For best customer satisfaction, could we please have a |
|
As far as I understand Flatpak, the |
|
To ship the binary, use RelWithDebInfo, the debug information is enough to get do some cursory debugging / tracing. Yes due to the optimizations applied, some functions might not be present at all (inlined), variables missing. |
Right, the Again, maybe I am overthinking this but what I am imagining is to have fully optimized stripped binaries but with debug symbols separated into the |
|
Is this Issue still relevant (aka are people still experiencing crashes with the latest flatpak)? |
|
@luciusDXL Things (no @tanuki2k @JKingweb @lordmonga @Admiral-Harkov please test the latest Flathub release on your systems. |
Thanks, I'm trying to clean up the issues. |
|
@JakeSmarter @tanuki2k @luciusDXL @lordmonga @JKingweb I have TFE github v 1.10.000-28-ge19bcde1+ and my system shows me no newer version. This version works very well, I can start Secbase and mods. |
@Admiral-Harkov Awesome, thanks for letting me know. I think I will close this issue then now that I have had two responses. It can be re-opened if needed. |
I ge the follow error when selecting start form the main menu.
The text was updated successfully, but these errors were encountered: