Giters

luciusDXL / TheForceEngine

Modern "Jedi Engine" replacement supporting Dark Forces, mods, and in the future Outlaws.

Home Page:https://TheForceEngine.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[linux] Crash when start new game

tanuki2k opened this issue · comments

commented

I ge the follow error when selecting start form the main menu.

[Main] The Force Engine v1.09.540-264-g341db341 
[Paths] Program Path: "/home/tanuki2k/"
[Paths] Program Data: "/home/tanuki2k/.local/share/TheForceEngine/"
[Paths] User Documents: "/home/tanuki2k/.local/share/TheForceEngine/"
[Paths] Source Data: "/home/tanuki2k/.local/share/Steam/steamapps/common/Dark Forces/Game/"
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[Display] Vertical Sync enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
[Audio] SDLAudio using interface 'pulseaudio'
[Audio] Device 00: DualSense wireless controller (PS5) Analog Surround 4.0
[Audio] Device 01: USB Audio S/PDIF Output
[Audio] Device 02: USB Audio Front Headphones
[Audio] Device 03: USB Audio Speakers
[Audio] Device 04: Navi 31 HDMI/DP Audio Digital Stereo (HDMI)
[Audio] Starting up audio stream for device 'DualSense wireless controller (PS5) Analog Surround 4.0'
[Startup] TFE_MidiPlayer::init
[Startup] TFE_Image::init
[Startup] TFE_FrontEndUI::init
[MemoryRegion] Allocated new memory block in region 'game' - new size is 1 blocks, total size is '8388608'
[MemoryRegion] Allocated new memory block in region 'level' - new size is 1 blocks, total size is '8388608'
[Progam Flow] The Force Engine Game Loop Started
[Game] Dark Forces Version: 1.0 (Build 1)
[Error : CrashHandler] Received Signal 11 errno 44 code 0
[Error : CrashHandler] faulting address 0x2c
[Error : CrashHandler] Backtrace 11:
[Error : CrashHandler] 000 theforceengine(+0x152bf1) [0x558caee01bf1]
[Error : CrashHandler] 001 /usr/lib/libc.so.6(+0x40770) [0x7fe50376c770]
[Error : CrashHandler] 002 /usr/lib/libc.so.6(+0x16c7c7) [0x7fe5038987c7]
[Error : CrashHandler] 003 theforceengine(+0xb5d6b) [0x558caed64d6b]
[Error : CrashHandler] 004 theforceengine(+0x84618) [0x558caed33618]
[Error : CrashHandler] 005 theforceengine(+0x7628a) [0x558caed2528a]
[Error : CrashHandler] 006 theforceengine(+0x17b47a) [0x558caee2a47a]
[Error : CrashHandler] 007 theforceengine(+0x15247) [0x558caecc4247]
[Error : CrashHandler] 008 /usr/lib/libc.so.6(+0x29cd0) [0x7fe503755cd0]
[Error : CrashHandler] 009 /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7fe503755d8a]
[Error : CrashHandler] 010 theforceengine(+0x18875) [0x558caecc7875]
zsh: segmentation fault (core dumped)  theforceengine
commented

Are you using the Flatpak version of TFE, and the Snap version of Steam by any chance?

commented

I'm experiencing what appears to be the same crash:

[Main] The Force Engine 
v1.09.530-13-gd029fe2b

[Paths] Program Path: "/home/jking/"
[Paths] Program Data: "/home/jking/.local/share/TheForceEngine/"
[Paths] User Documents: "/home/jking/.local/share/TheForceEngine/"
[Paths] Source Data: "/Games/Other/Dark Forces/DARK/"
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[Display] Vertical Sync enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
[Audio] SDLAudio using interface 'pulseaudio'
[Audio] Device 00: Starship/Matisse HD Audio Controller Digital Stereo (IEC958)
[Audio] Device 01: Navi 21/23 HDMI/DP Audio Controller Digital Stereo (HDMI)
[Audio] Device 02: SteelSeries Arctis 1 Wireless Analog Stereo
[Audio] Starting up audio stream for device '<autoselect>'
[Startup] TFE_MidiPlayer::init
[Startup] TFE_Polygon::init
[Startup] TFE_Image::init
[Startup] TFE_FrontEndUI::init
[MemoryRegion] Allocated new memory block in region 'game' - new size is 1 blocks, total size is '8388608'
[MemoryRegion] Allocated new memory block in region 'level' - new size is 1 blocks, total size is '8388608'
[Progam Flow] The Force Engine Game Loop Started
[Game] Dark Forces Version: 1.0 (Build 1)
[Error : CrashHandler] Received Signal 11 errno 44 code 0
[Error : CrashHandler] faulting address 0x2c
[Error : CrashHandler] Backtrace 11:
[Error : CrashHandler] 000 theforceengine(+0x1258a4) [0x5b965614c8a4]
[Error : CrashHandler] 001 /usr/lib/libc.so.6(+0x3c770) [0x7992aaf6e770]
[Error : CrashHandler] 002 /usr/lib/libc.so.6(+0x15871e) [0x7992ab08a71e]
[Error : CrashHandler] 003 theforceengine(+0x9643b) [0x5b96560bd43b]
[Error : CrashHandler] 004 theforceengine(+0x70eef) [0x5b9656097eef]
[Error : CrashHandler] 005 theforceengine(+0x63bc3) [0x5b965608abc3]
[Error : CrashHandler] 006 theforceengine(+0x14a1f6) [0x5b96561711f6]
[Error : CrashHandler] 007 theforceengine(+0x1302e) [0x5b965603a02e]
[Error : CrashHandler] 008 /usr/lib/libc.so.6(+0x25cd0) [0x7992aaf57cd0]
[Error : CrashHandler] 009 /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7992aaf57d8a]
[Error : CrashHandler] 010 theforceengine(+0x16c25) [0x5b965603dc25]
Segmentation fault (core dumped)

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.

commented

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 :(

commented

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
[Main] The Force Engine
v1.09.530-13-gd029fe2b

[Paths] Program Path: "/home/juancm/"
[Paths] Program Data: "/home/juancm/.local/share/TheForceEngine/"
[Paths] User Documents: "/home/juancm/.local/share/TheForceEngine/"
[Paths] Source Data: "/home/juancm/Games/Dark_Forces/Game/"
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[Display] Vertical Sync enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
[Audio] SDLAudio using interface 'pulseaudio'
[Audio] Device 00: Built-in Audio Analog Stereo
[Audio] Starting up audio stream for device ''
[Startup] TFE_MidiPlayer::init
[Startup] TFE_Polygon::init
[Startup] TFE_Image::init
[Startup] TFE_FrontEndUI::init
[MemoryRegion] Allocated new memory block in region 'game' - new size is 1 blocks, total size is '8388608'
[MemoryRegion] Allocated new memory block in region 'level' - new size is 1 blocks, total size is '8388608'
[Progam Flow] The Force Engine Game Loop Started
[Game] Dark Forces Version: 1.0 (Build 1)
[Error : CrashHandler] Received Signal 11 errno 44 code 0
[Error : CrashHandler] faulting address 0x2c
[Error : CrashHandler] Backtrace 11:
[Error : CrashHandler] 000 theforceengine(+0x124ee5) [0x55fa7bf19ee5]
[Error : CrashHandler] 001 /usr/lib/libc.so.6(+0x3c770) [0x79124fa5a770]
[Error : CrashHandler] 002 /usr/lib/libc.so.6(+0x15871e) [0x79124fb7671e]
[Error : CrashHandler] 003 theforceengine(+0x9269b) [0x55fa7be8769b]
[Error : CrashHandler] 004 theforceengine(+0x6c6e2) [0x55fa7be616e2]
[Error : CrashHandler] 005 theforceengine(+0x5f532) [0x55fa7be54532]
[Error : CrashHandler] 006 theforceengine(+0x149a18) [0x55fa7bf3ea18]
[Error : CrashHandler] 007 theforceengine(+0xcf72) [0x55fa7be01f72]
[Error : CrashHandler] 008 /usr/lib/libc.so.6(+0x25cd0) [0x79124fa43cd0]
[Error : CrashHandler] 009 /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x79124fa43d8a]
[Error : CrashHandler] 010 theforceengine(+0x10c15) [0x55fa7be05c15]
Segmentation fault (core dumped)

commented

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?

commented

the flatpak didnt work for me on Manjaro.

commented

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 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.

commented

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.

commented

I have the same crash with flatpak 1.09.540+ on Linux Mint 21.3, here is my error log (hope it helps)
(started from the console, same error when loading a mod instead of starting the original game)

[Main] The Force Engine v1.09.540+
[Main] /home/matthias/.var/app/io.github.theforceengine.tfe/data/
[Paths] Program Path: "/home/matthias/"
[Paths] Program Data: "/app/share/TheForceEngine/"
[Paths] User Documents: "/home/matthias/.var/app/io.github.theforceengine.tfe/config/"
[Paths] Source Data: "/home/matthias/.var/app/io.github.theforceengine.tfe/data/"
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
[Audio] SDLAudio using interface 'pulseaudio'
[Audio] Device 00: Tiger Lake-LP Smart Sound Technology Audio Controller HDMI / DisplayPort 3 Output
[Audio] Device 01: Tiger Lake-LP Smart Sound Technology Audio Controller HDMI / DisplayPort 2 Output
[Audio] Device 02: Tiger Lake-LP Smart Sound Technology Audio Controller HDMI / DisplayPort 1 Output
[Audio] Device 03: Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + Headphones
[Audio] Starting up audio stream for device ''
[Startup] TFE_MidiPlayer::init
[Startup] TFE_Polygon::init
[Startup] TFE_Image::init
[Startup] TFE_FrontEndUI::init
[MemoryRegion] Allocated new memory block in region 'game' - new size is 1 blocks, total size is '8388608'
[MemoryRegion] Allocated new memory block in region 'level' - new size is 1 blocks, total size is '8388608'
[a11y] Initializing caption system...
[Progam Flow] The Force Engine Game Loop Started
[Game] Dark Forces Version: 1.0 (Build 1)
[MemoryRegion] Allocated new memory block in region 'Landru' - new size is 1 blocks, total size is '4194304'
[MemoryRegion] Allocated new memory block in region 'Cutscene' - new size is 1 blocks, total size is '8388608'
[Error : CrashHandler] Received Signal 11 errno 16 code 0
[Error : CrashHandler] faulting address 0x10
[Error : CrashHandler] Backtrace 9:
[Error : CrashHandler] 000 theforceengine(+0x17adb3) [0x5b6d065c9db3]
[Error : CrashHandler] 001 /usr/lib/x86_64-linux-gnu/libc.so.6(+0x3ee80) [0x7a9741743e80]
[Error : CrashHandler] 002 theforceengine(+0x8276f) [0x5b6d064d176f]
[Error : CrashHandler] 003 theforceengine(+0x8295e) [0x5b6d064d195e]
[Error : CrashHandler] 004 theforceengine(+0x990a4) [0x5b6d064e80a4]
[Error : CrashHandler] 005 theforceengine(+0x192ba) [0x5b6d064682ba]
[Error : CrashHandler] 006 /usr/lib/x86_64-linux-gnu/libc.so.6(+0x2808a) [0x7a974172d08a]
[Error : CrashHandler] 007 /usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7a974172d14b]
[Error : CrashHandler] 008 theforceengine(+0x199b5) [0x5b6d064689b5]

commented

I am experiencing an immediate crash since the latest master commit v1.09.540-322-g4ca579ac+ too. 😞 Things have worked before. 😕

[Main] The Force Engine v1.09.540-322-g4ca579ac+
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[Display] Vertical Sync enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
[Audio] SDLAudio using interface 'pulseaudio'
[Audio] Device 00: Builtin Digital Stereo Device (IEC958)
[Audio] Starting up audio stream for device '<autoselect>'
[Startup] TFE_MidiPlayer::init
[Startup] TFE_Image::init
[Startup] TFE_FrontEndUI::init
[MemoryRegion] Allocated new memory block in region 'game' - new size is 1 blocks, total size is '8388608'
[MemoryRegion] Allocated new memory block in region 'level' - new size is 1 blocks, total size is '8388608'
[Progam Flow] The Force Engine Game Loop Started
[Game] Dark Forces Version: 1.0 (Build 1)
[Error : Agent] Cannot open DarkPilo.cfg
[MemoryRegion] Allocated new memory block in region 'Landru' - new size is 1 blocks, total size is '4194304'
[MemoryRegion] Allocated new memory block in region 'Cutscene' - new size is 1 blocks, total size is '8388608'
theforceengine: /run/build/tfe/TheForceEngine/TFE_RenderBackend/Win32OpenGL/textureGpu.cpp:53: bool TextureGpu::create(u32, u32, TexFormat, bool, MagFilter): Assertion `error == GL_NO_ERROR' failed.
[Error : CrashHandler] Received Signal 6 errno 2 code 0
[Error : CrashHandler] Backtrace 22:
[Error : CrashHandler] 000 theforceengine(+0x159be0) [0xaaaaccfe9be0]
[Error : CrashHandler] 001 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0xffff995a17dc]
[Error : CrashHandler] 002 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x86a40) [0xffff98d56a40]
[Error : CrashHandler] 003 /usr/lib/aarch64-linux-gnu/libc.so.6(raise+0x1c) [0xffff98d0fcac]
[Error : CrashHandler] 004 /usr/lib/aarch64-linux-gnu/libc.so.6(abort+0xf0) [0xffff98cfad7c]
[Error : CrashHandler] 005 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x393e0) [0xffff98d093e0]
[Error : CrashHandler] 006 /usr/lib/aarch64-linux-gnu/libc.so.6(__assert_perror_fail+0) [0xffff98d09450]
[Error : CrashHandler] 007 theforceengine(+0x14bffc) [0xaaaaccfdbffc]
[Error : CrashHandler] 008 theforceengine(+0x146288) [0xaaaaccfd6288]
[Error : CrashHandler] 009 theforceengine(+0x1463bc) [0xaaaaccfd63bc]
[Error : CrashHandler] 010 theforceengine(+0x148668) [0xaaaaccfd8668]
[Error : CrashHandler] 011 theforceengine(+0x148778) [0xaaaaccfd8778]
[Error : CrashHandler] 012 theforceengine(+0x11eb80) [0xaaaaccfaeb80]
[Error : CrashHandler] 013 theforceengine(+0x11ec4c) [0xaaaaccfaec4c]
[Error : CrashHandler] 014 theforceengine(+0x7af90) [0xaaaaccf0af90]
[Error : CrashHandler] 015 theforceengine(+0x800c4) [0xaaaaccf100c4]
[Error : CrashHandler] 016 theforceengine(+0x887e0) [0xaaaaccf187e0]
[Error : CrashHandler] 017 theforceengine(+0x1ad284) [0xaaaacd03d284]
[Error : CrashHandler] 018 theforceengine(+0x1add10) [0xaaaacd03dd10]
[Error : CrashHandler] 019 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x2b440) [0xffff98cfb440]
[Error : CrashHandler] 020 /usr/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0xffff98cfb518]
[Error : CrashHandler] 021 theforceengine(+0x13c30) [0xaaaaccea3c30]

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 Classic (Software) renderer.
Unfortunately, although the binaries have debug symbols the trace lacks source line numbers. 🤷‍♂️ I will have to investigate further.
🤔 Could this possibly be the culprit?

theforceengine: /run/build/tfe/TheForceEngine/TFE_RenderBackend/Win32OpenGL/textureGpu.cpp:53: bool TextureGpu::create(u32, u32, TexFormat, bool, MagFilter): Assertion `error == GL_NO_ERROR' failed.

However, using the Mesa 3D software renderer with LIBGL_ALWAYS_SOFTWARE=1 works fine.

commented 
[Main] The Force Engine v1.09.540-332-g6b5aad24+
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
[Audio] SDLAudio using interface 'pulseaudio'
[Audio] Device 00: Built-in Digital Stereo Sound Device (IEC958)
[Audio] Starting up audio stream for device '<autoselect>'
[Startup] TFE_MidiPlayer::init
[Startup] TFE_Image::init
[Startup] TFE_FrontEndUI::init
[MemoryRegion] Allocated new memory block in region 'game' - new size is 1 blocks, total size is '8388608'
[MemoryRegion] Allocated new memory block in region 'level' - new size is 1 blocks, total size is '8388608'
[Progam Flow] The Force Engine Game Loop Started
[Game] Dark Forces Version: 1.0 (Build 1)
[Error : HUD] Cannot load font 'AmoNum2.fnt'
[Error : HUD] Cannot load font 'SuperWep2.fnt'
[Error : HUD] Cannot load font 'ArmNum2.fnt'
[Error : HUD] Cannot load font 'HelNum2.fnt'
[Error : Agent] Cannot open DarkPilo.cfg
[MemoryRegion] Allocated new memory block in region 'Landru' - new size is 1 blocks, total size is '4194304'
[MemoryRegion] Allocated new memory block in region 'Cutscene' - new size is 1 blocks, total size is '8388608'
theforceengine: /run/build/tfe/TheForceEngine/TFE_RenderBackend/Win32OpenGL/textureGpu.cpp:53: bool TextureGpu::create(u32, u32, TexFormat, bool, MagFilter): Assertion `error == GL_NO_ERROR' failed.
[Error : CrashHandler] Received Signal 6 errno 2 code 0
[Error : CrashHandler] Backtrace 22:
[Error : CrashHandler] 000 theforceengine(+0x160994) [0xaaaabc660994]
[Error : CrashHandler] 001 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0xffffad6027dc]
[Error : CrashHandler] 002 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x86a40) [0xffffacdb6a40]
[Error : CrashHandler] 003 /usr/lib/aarch64-linux-gnu/libc.so.6(raise+0x1c) [0xffffacd6fcac]
[Error : CrashHandler] 004 /usr/lib/aarch64-linux-gnu/libc.so.6(abort+0xf0) [0xffffacd5ad7c]
[Error : CrashHandler] 005 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x393e0) [0xffffacd693e0]
[Error : CrashHandler] 006 /usr/lib/aarch64-linux-gnu/libc.so.6(__assert_perror_fail+0) [0xffffacd69450]
[Error : CrashHandler] 007 theforceengine(+0x14e28c) [0xaaaabc64e28c]
[Error : CrashHandler] 008 theforceengine(+0x148500) [0xaaaabc648500]
[Error : CrashHandler] 009 theforceengine(+0x148634) [0xaaaabc648634]
[Error : CrashHandler] 010 theforceengine(+0x14a8f8) [0xaaaabc64a8f8]
[Error : CrashHandler] 011 theforceengine(+0x14aa08) [0xaaaabc64aa08]
[Error : CrashHandler] 012 theforceengine(+0x1205d0) [0xaaaabc6205d0]
[Error : CrashHandler] 013 theforceengine(+0x12069c) [0xaaaabc62069c]
[Error : CrashHandler] 014 theforceengine(+0x7c2e4) [0xaaaabc57c2e4]
[Error : CrashHandler] 015 theforceengine(+0x81418) [0xaaaabc581418]
[Error : CrashHandler] 016 theforceengine(+0x89b3c) [0xaaaabc589b3c]
[Error : CrashHandler] 017 theforceengine(+0x1b4038) [0xaaaabc6b4038]
[Error : CrashHandler] 018 theforceengine(+0x1b4ac4) [0xaaaabc6b4ac4]
[Error : CrashHandler] 019 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x2b440) [0xffffacd5b440]
[Error : CrashHandler] 020 /usr/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0xffffacd5b518]
[Error : CrashHandler] 021 theforceengine(+0x13fb0) [0xaaaabc513fb0]

😢 Continues to crash. Things got even worse. Now, TFE crashes on exit too:

[Error : CrashHandler] Received Signal 11 errno 0 code 0
[Error : CrashHandler] faulting address (nil)
[Error : CrashHandler] Backtrace 10:
[Error : CrashHandler] 000 theforceengine(+0x160994) [0xaaaacdb50994]
[Error : CrashHandler] 001 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0xffffb0d977dc]
[Error : CrashHandler] 002 theforceengine(+0x412b8) [0xaaaacda312b8]
[Error : CrashHandler] 003 theforceengine(+0x41340) [0xaaaacda31340]
[Error : CrashHandler] 004 theforceengine(+0x87584) [0xaaaacda77584]
[Error : CrashHandler] 005 theforceengine(+0xc9594) [0xaaaacdab9594]
[Error : CrashHandler] 006 theforceengine(+0x1b4b68) [0xaaaacdba4b68]
[Error : CrashHandler] 007 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x2b440) [0xffffb04eb440]
[Error : CrashHandler] 008 /usr/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0xffffb04eb518]
[Error : CrashHandler] 009 theforceengine(+0x13fb0) [0xaaaacda03fb0]
commented

@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;
 }
commented

FYI, I am running on the “Broadcom V3D 4.2.12” OpenGL renderer (or Broadcom VideoCore 6 GPU), aka the Raspberry Pi 4B GPU.
Anyway, I have tried running gdb.

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:875

Indeed, it crashes, or rather aborts, on the assert(). Btw, imho using assert() is a hack than good programming style. assert() is meant as a development and debugging tool only than something that should be found in release code. The proper way to deactivate assertions is to define the NDEBUG macro. By doing so things returned to what they had been before. Hence, you may want to add this:

--- 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
commented

FYI, I am running on the “Broadcom V3D 4.2.12” OpenGL renderer (or Broadcom VideoCore 6 GPU), aka the Raspberry Pi 4B GPU. Anyway, I have tried running gdb.

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:875

Indeed, it crashes, or rather aborts, on the assert().

Did you catcht the error code returned by glGetError()?
This code has been developed against windows gl drivers, and additionally tested on linux x86 gl drivers, where it mostly works just fine. Might uncover a bug/false assumption in either TFE or the V3D GL driver.

Btw, imho using assert() is a hack than good programming style. assert() is meant as a development and debugging tool only than something that should be found in release code. The proper way to deactivate assertions is to define the NDEBUG macro. By doing so things returned to what they had been before. Hence, you may want to add this:

--- 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()

i'm on the fence about this. it did catch something unexpected (i.e. your particular gl setup),
and at least a helpful text about the offending source line was printed.

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

See #407 to fix that.

commented

Did you catcht the error code returned by glGetError()?

Right, now that the assert() does not cause the program to abort before logging the error value, things are easy. 🤔 Thus, it might be a good idea for any assert()s to come after error logging messages, so that we get a chance to actually diagnose errors.

[Warning : TextureGPU - OpenGL] Pre-existing OpenGL error: 0x500 when calling TextureGpu::create().

0x500 evaluates to GL_INVALID_ENUM. I am not sure what GL command sets this error code before the assert(). Anyhow, I would strongly recommend to test every GL command for errors that can generate GL errors going forward. It may look ugly and seem like a performance penalty but glGetError() is not as expensive as one might think.

See #407 to fix that.

I have not tried the #407 fix yet but may give a try should I have more time.

commented

Did you catcht the error code returned by glGetError()?

Right, now that the assert() does not cause the program to abort before logging the error value, things are easy. 🤔 Thus, it might be a good idea for any assert()s to come after error logging messages, so that we get a chance to actually diagnose errors.

[Warning : TextureGPU - OpenGL] Pre-existing OpenGL error: 0x500 when calling TextureGpu::create().

Do you want to try something? I've implemented a rudimentary version of the gl debug callback.
Find it here: https://github.com/mlauss2/TheForceEngine/tree/test2

with mesa it prints something like this:

[RenderBackend] GL Info: 4.6 (Compatibility Profile) Mesa 24.2.0-devel (git-724bb7fa15), AMD, AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.9.3)
[RenderBackend] OpenGL Device Tier: 3
[OpenGL] Debug Callback installed.
[OpenGL DEBUG] 8246 824c 0001 9146 45 >GL_INVALID_ENUM in glGetIntegerv(pname=0xcfe)<

Thanks!

commented

Do you want to try something? I've implemented a rudimentary version of the gl debug callback.
Find it here: https://github.com/mlauss2/TheForceEngine/tree/test2

Thanks, I’ll give it a shot sometime.

with mesa it prints something like this:

[RenderBackend] GL Info: 4.6 (Compatibility Profile) Mesa 24.2.0-devel (git-724bb7fa15), AMD, AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.9.3)
[RenderBackend] OpenGL Device Tier: 3
[OpenGL] Debug Callback installed.
[OpenGL DEBUG] 8246 824c 0001 9146 45 >GL_INVALID_ENUM in glGetIntegerv(pname=0xcfe)<

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 assert() and friends it may also be a good idea to have a proper SIGABRT handler installed. In other words, the program should be terminated gracefully with a non 0 value to avoid any memory leaks and resource locks, something neither the Windows nor the Linux handler does currently. Actually, this should rather happen on all handled signals. Please note that even a severe signal like SIGSEGV does not complete memory reads or writes, so most of the time there is a good chance to terminate gracefully.

commented

Nice, I have not tried it with Mesa 3D’s software renderer. So, there is a GL error after all.

Interesting, Mesa 3D’s software renderer does not log a GL error in TextureGpu::create().

commented

Nice, I have not tried it with Mesa 3D’s software renderer. So, there is a GL error after all.

Interesting, Mesa 3D’s software renderer does not log a GL error in TextureGpu::create().

Well, I think you need to sprinkle the code with glGetError() calls to find out what V3D doesn't like
Oh and that error callback is a GL4.3+ feature, softpipe/llvmpipe and V3d might not even support it.
I just know that radeonsi on linux does.

commented

Oh and that error callback is a GL4.3+ feature, softpipe/llvmpipe and V3d might not even support it.

Yeah, V3D on VideoCore 6 does not support OpenGL 4.3. However, it supports the GL_ARB_debug_output extension which is basically almost identical to the GL_AMD_debug_output extension. Note that GL_ARB_debug_output requires as low as OpenGL 1.1 but the extension spec was written against OpenGL 4.0, hence ruling out GL_ARB_debug_output support on OpenGL version alone is not the best idea.

commented

@mlauss2 I have tested your test2 branch and it looks to run flawlessly. The new GL debug callback throws a bunch of Mesa 3D stats but no errors:

[TFEGLErrorCallback] 00008248 00008251 1 0000826B 141 “MESA_SHADER_FRAGMENT shader: 14 inst, 4 threads, 0 loops, 4 uniforms, 5 max-temps, 0:0 spills:fills, 0 sfu-stalls, 14 inst-and-stalls, 1 nops”
[TFEGLErrorCallback] 00008248 00008251 1 0000826B 139 “MESA_SHADER_VERTEX shader: 20 inst, 4 threads, 0 loops, 4 uniforms, 5 max-temps, 0:0 spills:fills, 0 sfu-stalls, 20 inst-and-stalls, 2 nops”
[TFEGLErrorCallback] 00008248 00008251 1 0000826B 143 “MESA_SHADER_VERTEX_BIN shader: 21 inst, 4 threads, 0 loops, 2 uniforms, 6 max-temps, 0:0 spills:fills, 0 sfu-stalls, 21 inst-and-stalls, 2 nops”

I am not sure where that GL_INVALID_ENUM had come from. Perhaps it had been left from device tier detection?
Anyway, when I force, say, OpenGL 3.1 then TFE aborts rather dirty on startup. I think it should terminate gracefully here.

[RenderBackend] GL Info: 3.1 Mesa 24.0.7 (git-cc175010c5), Broadcom, V3D 4.2.14
[RenderBackend] OpenGL Device Tier: 1 version 301
[Error : RenderBackend] OpenGL capabilities insufficient, sorry
[Critical : GPU] Cannot initialize GPU/Window.
theforceengine: /run/build/tfe/TheForceEngine/TFE_System/log.cpp:98: void TFE_System::logWrite(LogWriteType, const char*, const char*, ...): Assertion `0' failed.
[Error : CrashHandler] Received Signal 6 errno 2 code 0
[Error : CrashHandler] Backtrace 12:
[Error : CrashHandler] 000 theforceengine(+0x167d0c) [0xaaaac4487d0c]
[Error : CrashHandler] 001 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0xffffb7c227dc]
[Error : CrashHandler] 002 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x86a00) [0xffffb74b6a00]
[Error : CrashHandler] 003 /usr/lib/aarch64-linux-gnu/libc.so.6(raise+0x1c) [0xffffb746fc6c]
[Error : CrashHandler] 004 /usr/lib/aarch64-linux-gnu/libc.so.6(abort+0xf0) [0xffffb745ad3c]
[Error : CrashHandler] 005 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x393a0) [0xffffb74693a0]
[Error : CrashHandler] 006 /usr/lib/aarch64-linux-gnu/libc.so.6(__assert_perror_fail+0) [0xffffb7469410]
[Error : CrashHandler] 007 theforceengine(+0x16429c) [0xaaaac448429c]
[Error : CrashHandler] 008 theforceengine(+0x177e0) [0xaaaac43377e0]
[Error : CrashHandler] 009 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x2b400) [0xffffb745b400]
[Error : CrashHandler] 010 /usr/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0xffffb745b4d8]
[Error : CrashHandler] 011 theforceengine(+0x17a70) [0xaaaac4337a70]
commented

7 theforceengine(+0x1642

@mlauss2 I have tested your test2 branch and it looks to run flawlessly. The new GL debug callback throws a bunch of Mesa 3D stats but no errors:

[TFEGLErrorCallback] 00008248 00008251 1 0000826B 141 “MESA_SHADER_FRAGMENT shader: 14 inst, 4 threads, 0 loops, 4 uniforms, 5 max-temps, 0:0 spills:fills, 0 sfu-stalls, 14 inst-and-stalls, 1 nops”
[TFEGLErrorCallback] 00008248 00008251 1 0000826B 139 “MESA_SHADER_VERTEX shader: 20 inst, 4 threads, 0 loops, 4 uniforms, 5 max-temps, 0:0 spills:fills, 0 sfu-stalls, 20 inst-and-stalls, 2 nops”
[TFEGLErrorCallback] 00008248 00008251 1 0000826B 143 “MESA_SHADER_VERTEX_BIN shader: 21 inst, 4 threads, 0 loops, 2 uniforms, 6 max-temps, 0:0 spills:fills, 0 sfu-stalls, 21 inst-and-stalls, 2 nops”

Thanks for testing!

Yeah, radeonsi on my system also spits out stats from the shader compiler via this debug.
(8248 = shader compiler, 8251 = debug type other, 826B = severity notification)
I'll fine tune this a bit to e.g. only show SEVERITY_HIGH.

I am not sure where that GL_INVALID_ENUM had come from. Perhaps it had been left from device tier detection? Anyway, when I force, say, OpenGL 3.1 then TFE aborts rather dirty on startup. I think it should terminate gracefully here.

[RenderBackend] GL Info: 3.1 Mesa 24.0.7 (git-cc175010c5), Broadcom, V3D 4.2.14
[RenderBackend] OpenGL Device Tier: 1 version 301
[Error : RenderBackend] OpenGL capabilities insufficient, sorry
[Critical : GPU] Cannot initialize GPU/Window.
theforceengine: /run/build/tfe/TheForceEngine/TFE_System/log.cpp:98: void TFE_System::logWrite(LogWriteType, const char*, const char*, ...): Assertion `0' failed.
[Error : CrashHandler] Received Signal 6 errno 2 code 0
[Error : CrashHandler] Backtrace 12:
[Error : CrashHandler] 000 theforceengine(+0x167d0c) [0xaaaac4487d0c]
[Error : CrashHandler] 001 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0xffffb7c227dc]
[Error : CrashHandler] 002 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x86a00) [0xffffb74b6a00]
[Error : CrashHandler] 003 /usr/lib/aarch64-linux-gnu/libc.so.6(raise+0x1c) [0xffffb746fc6c]
[Error : CrashHandler] 004 /usr/lib/aarch64-linux-gnu/libc.so.6(abort+0xf0) [0xffffb745ad3c]
[Error : CrashHandler] 005 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x393a0) [0xffffb74693a0]
[Error : CrashHandler] 006 /usr/lib/aarch64-linux-gnu/libc.so.6(__assert_perror_fail+0) [0xffffb7469410]
[Error : CrashHandler] 007 theforceengine(+0x16429c) [0xaaaac448429c]
[Error : CrashHandler] 008 theforceengine(+0x177e0) [0xaaaac43377e0]
[Error : CrashHandler] 009 /usr/lib/aarch64-linux-gnu/libc.so.6(+0x2b400) [0xffffb745b400]
[Error : CrashHandler] 010 /usr/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0xffffb745b4d8]
[Error : CrashHandler] 011 theforceengine(+0x17a70) [0xaaaac4337a70]

entry "007" is the faulting one, can you please paste the output of
"addr2line -e theforceengine 0x16429c" it should print a file name and line number.

Thanks!

commented

Eh, the abort is due to the "Critical" in "[Critical : GPU] Cannot initialize GPU/Window."
there's an assert in the logging code which trips when a critical log message is printed.
Without this assert it does shut down gracefully.
I agree with you that these asserts should go away for a release build.

commented

Hello All,
if you still have this problem on launch, can you please build TFE with debug symbols enabled, run it under gdb and show the backtrace?

at the root of the source directory, build with:

rm -rf __build ; mkdir __build ; cd __build ; CXXFLAGS="-O2 -ggdb3 -pipe" CFLAGS="-O2 -ggdb3 -pipe" cmake -DDISABLE_SYSMIDI=YES .. ; make ; gdb ./theforceengine

at the gdb prompt type "r" to run it, then set it to "windowed" mode so you can see the console window.
Start the game, Wen it crashes, you'll see something like "Program received SIGSEGV" in the gdb window.
Type "bt" to print the backtrace and paste it here please.

Thanks!

commented

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.

commented

For context when compiling on Windows assert() is compiled out for RELEASE builds (which is what gets distributed).
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 NDEBUG macro when building the release flavor, hence you would need to add add_compile_definitions(NDEBUG) explicitly to CMakeLists.txt on other build environments.

commented

with the default build instructions, cmake does add the -DNDEBUG and there are no assert()s left.

$ readelf -Wa theforceengine | grep assert
  7259: 00000000002430d0  1117 FUNC    WEAK   DEFAULT   14 std::__detail::_Compiler<std::__cxx11::regex_traits<char> >::_M_assertion()

vs.

$ readelf -Wa theforceengine | grep assert
00000000005c9110  0000002500000007 R_X86_64_JUMP_SLOT     0000000000000000 __assert_fail@GLIBC_2.2.5 + 0  <<<<<<<<<<<<
    37: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __assert_fail@GLIBC_2.2.5 (3)  <<<<<<<<<<<
  4964: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __assert_fail@GLIBC_2.2.5      <<<<<<<<<<<
  7370: 0000000000246c50  1117 FUNC    WEAK   DEFAULT   14 std::__detail::_Compiler<std::__cxx11::regex_traits<char> >::_M_assertion()

The original issue looks like a member of null-pointered struct being accessed:

[Error : CrashHandler] faulting address 0x2c
commented

with the default build instructions, cmake does add the -DNDEBUG and there are no assert()s left.

$ 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.

commented

with the default build instructions, cmake does add the -DNDEBUG and there are no assert()s left.

$ 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"

commented

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.

commented

My two cents to this is that I have mixed feelings about CMAKE_C[XX]_FLAGS_RELWITHDEBINFO’s effectiveness of mixing -O2 and -g (except for -Og) in a release build. Imho there is something fundamentally flawed in this concept. However, I am open to learning something new and won’t object if it makes people happy.

…if unstripped builds are causing problems here then obviously making a RelWithDebInfo build should probably do the trick.

Just to clarify; stripped or not, debug symbols or not, the issue here is that CMAKE_C[XX]_FLAGS_DEBUG by design does not define the NDEBUG macro.

commented

My two cents to this is that I have mixed feelings about CMAKE_C[XX]_FLAGS_RELWITHDEBINFO’s effectiveness of mixing -O2 and -g (except for -Og) in a release build.

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.

commented

Good to know the assert issue is due to the Flatpak build - that makes a lot more sense.

commented

Maybe I am exaggerating this but GCC’s section 3.10 Options for Debugging Your Program of the manual says:

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally be surprising: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops. Nevertheless it is possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

If you are not using some other optimization option, consider using -Og (see Options That Control Optimization) with -g. With no -O option at all, some compiler passes that collect information useful for debugging do not run at all, so that -Og may result in a better debugging experience.

However, section 3.11 Options That Control Optimization says:

Without any optimization option, the compiler’s goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you expect from the source code.

Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program.
…
-O0
Reduce compilation time and make debugging produce the expected results. This is the default.
-Og
Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.

Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging

@fpiesche For best customer satisfaction, could we please have a Release CMAKE_BUILD_TYPE for daily driving and a Debug CMAKE_BUILD_TYPE (potentially with -Og) for the .Debug Flatpak extension? By default CMAKE_C[XX]_FLAGS_DEBUG specify only -g.

commented

As far as I understand Flatpak, the .Debug extension is automatically generated to contain only the debug symbols created during the main build, so I think RelWithDbgInfo is probably our only real option here. I'll do a little research on whether the .Debug extension can be built separately and update...

commented

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.
If anyone wants to really step through an issue, they can then rebuild the source with -Og applied.

commented

As far as I understand Flatpak, the .Debug extension is automatically generated to contain only the debug symbols created during the main build, so I think RelWithDbgInfo is probably our only real option here.

Right, the .Debug extension ships debug symbols only, no binaries.

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 .Debug extension. I am not sure if setting strip: true and no-debuginfo: false in the Flatpak build manifest automatically chooses RelWithDbgInfo for the CMake build system because we would like to rather have pure (stripped) Release built binaries.