Each release seems to almost always break the project

[bfg01]

First, regarding the "segmentation fault" error, I tried in other 2 different rigs, and got exactly the same problem. Making them 3 in total then, I must mention that all of them are different brands, different hardware, and even different years of release. So I dare to discard hardware problems.

That was yesterday. Git-cloned today yet again... full of coding errors.
Even very first complain is "build.sh: line 2: HOME unknown command"
Then full of errors which seemingly had to do mainly with the save dir implementation. Or at least the first lines of output.

I'm actually no coder, so I cannot throw points of view regarding coding style or practices. However, and as only thing to suspect, I was taught that factory/unstable systems are meant for testing and experimentation; never for daily drivers.

Perhaps you're an enthusiastic tester of things, and that's actually excellent. However, if you're sharing a project like this one (just posting in a website such as Github and even making a wiki page for usage is "sharing"), could you perhaps also think about all those ones using stable branch systems, and test more before releasing?
With all my ignorance I'm suspecting the different glibc and gcc versions...

"I don't have a Debian Stable installation" What about live systems? That if you find setting up a VM would be too time consuming...

Could we even try locating and asking @svkaiser for some help?

[Wolf3s]

First, regarding the "segmentation fault" error, I tried in other 2 different rigs, and got exactly the same problem. Making them 3 in total then, I must mention that all of them are different brands, different hardware, and even different years of release. So I dare to discard hardware problems.

That was yesterday. Git-cloned today yet again... full of coding errors. Even very first complain is "build.sh: line 2: HOME unknown command" Then full of errors which seemingly had to do mainly with the save dir implementation. Or at least the first lines of output.

I'm actually no coder, so I cannot throw points of view regarding coding style or practices. However, and as only thing to suspect, I was taught that factory/unstable systems are meant for testing and experimentation; never for daily drivers.

Perhaps you're an enthusiastic tester of things, and that's actually excellent. However, if you're sharing a project like this one (just posting in a website such as Github and even making a wiki page for usage is "sharing"), could you perhaps also think about all those ones using stable branch systems, and test more before releasing? With all my ignorance I'm suspecting the different glibc and gcc versions...

"I don't have a Debian Stable installation" What about live systems? That if you find setting up a VM would be too time consuming...

Could we even try locating and asking @svkaiser for some help?

Are you mean that the build.sh is not working properly? Do you have installed the dependencies on the readme?

[atsb]

What we will do is start creating branches for features and not merge them until they are confirmed working. That should help keep master more stable.

I've reverted the user directory fix for now, until there is a real demand for Linux users and packaging / wants / needs / dreams etc.. then we will keep the directories as you suggested.

About the segfault, I will test on a RPI3 today, that is the only stable system I have (Raspbian). I simply don't have the time to create virtual machines and test on every conceivable hardware.

Kaiser also cannot help, so please don't bother him or ping him. He works at nightdive and did the remaster, this is a conflict of interest and he won't be able to. It isn't fair on him to pester about something he cannot do.

The next release will have a ton of fixes and will be the first truly stable build. This won’t be soon though, maybe in a few weeks to a month from now.

Let us do the developing in our own time.

[atsb]

So I just tried it on a raspberry pi 3 1GB using Raspbian. It compiles and it does run. There were a few segfaults with fluidsynth and OpenGL (video ram) which isn't enough for the software.

To help us with the issue, if you have GDB installed, could you do a:

1. gdb ./Doom64EX-Plus
2. In the GDB terminal, type: run -window
3. Once the crash happens, please type: bt
4. This will bring up a stacktrace where we can see where it is crashing

[bfg01]

Just after having git-cloned:

$ gdb ./DOOM64EX-Plus; echo $?
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./DOOM64EX-Plus...
(gdb) run -window
Starting program: /home/user/Downloads/Doom64EX-Plus/src/engine/DOOM64EX-Plus -window
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Setting up game input and commands
M_LoadDefaults: Loading game configuration
WARNING: Unknown Key
I_Init: Setting up machine state.
[Detaching after fork from child process 26072]
[New Thread 0x7fffedfa7700 (LWP 26075)]
[New Thread 0x7fffed7a6700 (LWP 26076)]
[New Thread 0x7fffecfa5700 (LWP 26077)]
[New Thread 0x7fffdffff700 (LWP 26078)]
[New Thread 0x7fffdf7fe700 (LWP 26079)]
[New Thread 0x7fffdeffd700 (LWP 26080)]
[New Thread 0x7fffde7fc700 (LWP 26081)]
[New Thread 0x7fffddffb700 (LWP 26082)]
[New Thread 0x7fffdd7fa700 (LWP 26083)]
[New Thread 0x7fffdcff9700 (LWP 26084)]
[New Thread 0x7fffbffff700 (LWP 26085)]
[New Thread 0x7fffbf7fe700 (LWP 26086)]
D_Init: Init DOOM parameters
W_Init: Init WADfiles.
W_AddFile: Adding /home/user/Downloads/Doom64EX-Plus/src/engine/doom64ex-plus.wad
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
libpng warning: Interlace handling should be turned on when using png_read_image
P_Init: Init Playloop state.
NET_Init: Init network subsystem.
S_Init: Setting up sound.
[New Thread 0x7fffbeffd700 (LWP 26087)]
fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable
fluidsynth: error: Couldn't find the requested audio driver 'DEFAULT_FLUID_DRIVER'.
fluidsynth: Valid drivers are: alsa, file, jack, oss, pulseaudio, sdl2
WARNING: I_InitSequencer: failed to create audio driverD_CheckNetGame: Checking network game status.
ST_Init: Init status bar.
GL_Init: Init OpenGL
GL_VENDOR: Mesa/X.org
GL_VERSION: 3.1 Mesa 20.3.5
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS_ARB: 8
GL Extension: GL_ARB_multitexture = true
GL Extension: GL_EXT_compiled_vertex_array = true
GL Extension: GL_ARB_texture_env_combine = true
GL Extension: GL_EXT_texture_env_combine = true
GL Extension: GL_EXT_texture_filter_anisotropic = false

Thread 1 "DOOM64EX-Plus" received signal SIGSEGV, Segmentation fault.
0x0000555555588898 in GL_BindGfxTexture (name=0x5555555c7902 "USLEGAL", alpha=1) at gl_texture.c:355
355		gfxheight[gfxid] = height;
(gdb) bt
#0  0x0000555555588898 in GL_BindGfxTexture (name=0x5555555c7902 "USLEGAL", alpha=1) at gl_texture.c:355
#1  0x00005555555849db in Draw_GfxImage (x=32, y=72, name=0x5555555c7902 "USLEGAL", color=4294967295, alpha=1) at gl_draw.c:45
#2  0x000055555556901d in Legal_Drawer () at d_main.c:559
#3  0x000055555556892f in D_MiniLoop
    (start=0x555555568ebf <Legal_Start>, stop=0x0, draw=0x555555568fea <Legal_Drawer>, tick=0x555555569020 <Legal_Ticker>) at d_main.c:261
#4  0x00005555555693da in D_SplashScreen () at d_main.c:694
#5  0x0000555555569e71 in D_DoomMain () at d_main.c:1015
#6  0x00005555555be1f8 in main (argc=2, argv=0x7fffffffe2a8) at i_main.c:501
(gdb) n
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) [Thread 0x7fffbeffd700 (LWP 26087) exited]
[Thread 0x7fffbf7fe700 (LWP 26086) exited]
[Thread 0x7fffdcff9700 (LWP 26084) exited]
[Thread 0x7fffdd7fa700 (LWP 26083) exited]
[Thread 0x7fffddffb700 (LWP 26082) exited]
[Thread 0x7fffde7fc700 (LWP 26081) exited]
[Thread 0x7fffdeffd700 (LWP 26080) exited]
[Thread 0x7fffdf7fe700 (LWP 26079) exited]
[Thread 0x7fffdffff700 (LWP 26078) exited]
[Thread 0x7fffecfa5700 (LWP 26077) exited]
[Thread 0x7fffed7a6700 (LWP 26076) exited]
[Thread 0x7fffedfa7700 (LWP 26075) exited]
[Thread 0x7ffff61ab780 (LWP 26068) exited]
n
Cannot execute this command without a live selected thread.
(gdb) n
Cannot execute this command without a live selected thread.
(gdb) q
A debugging session is active.

	Inferior 1 [process 26068] will be killed.

Quit anyway? (y or n) y
0
$

After deleting all source stuff, leaving only program's files:

[...]
Thread 1 "DOOM64EX-Plus" received signal SIGSEGV, Segmentation fault.
0x0000555555588898 in GL_BindGfxTexture (name=0x5555555c7902 "USLEGAL", alpha=1) at gl_texture.c:355
355	gl_texture.c: No such file or directory.
(gdb) bt
#0  0x0000555555588898 in GL_BindGfxTexture (name=0x5555555c7902 "USLEGAL", alpha=1) at gl_texture.c:355
#1  0x00005555555849db in Draw_GfxImage (x=32, y=72, name=0x5555555c7902 "USLEGAL", color=4294967295, alpha=1) at gl_draw.c:45
#2  0x000055555556901d in Legal_Drawer () at d_main.c:559
#3  0x000055555556892f in D_MiniLoop
    (start=0x555555568ebf <Legal_Start>, stop=0x0, draw=0x555555568fea <Legal_Drawer>, tick=0x555555569020 <Legal_Ticker>) at d_main.c:261
#4  0x00005555555693da in D_SplashScreen () at d_main.c:694
#5  0x0000555555569e71 in D_DoomMain () at d_main.c:1015
#6  0x00005555555be1f8 in main (argc=2, argv=0x7fffffffe2c8) at i_main.c:501
(gdb) n
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) [Thread 0x7fffbeffd700 (LWP 27267) exited]
[Thread 0x7fffbf7fe700 (LWP 27266) exited]
[Thread 0x7fffbffff700 (LWP 27265) exited]
[Thread 0x7fffdcff9700 (LWP 27264) exited]
[Thread 0x7fffdd7fa700 (LWP 27263) exited]
[Thread 0x7fffddffb700 (LWP 27262) exited]
[Thread 0x7fffde7fc700 (LWP 27261) exited]
[Thread 0x7fffdeffd700 (LWP 27260) exited]
[Thread 0x7fffdf7fe700 (LWP 27259) exited]
[Thread 0x7fffdffff700 (LWP 27258) exited]
[Thread 0x7fffecfa5700 (LWP 27257) exited]
[Thread 0x7fffed7a6700 (LWP 27256) exited]
[Thread 0x7fffedfa7700 (LWP 27255) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
n
The program is not being run.
(gdb) q
0
$

Still don't get why GDB says "Debian 10", if I'm clearly on 11...

[atsb]

Ok now we are onto something. This is where my Raspberry Pi 3 segfaulted on after trying to start a newgame, except mine crashed on line 183. Very interesting. Thanks!

[atsb]

So I have been able to reproduce this issue exactly, on Ubuntu and ZorinOS, both LTS.

Question is... why does this only hapen on 'stable' systems.... this is going to be a pain.

[atsb]

@bfg01 - fixed in commit 3182813

Pulling immediately from master will work for you now.

Apologies for the complications, nothing will be merged unless Windows, Linux, LTS Linux and RPI3 are confirmed working in future.

[bfg01]

Thanks very much! It finally worked now.

You already mentioned that custom save locations will wait for a bit longer until project reaches a more stable point, or so I understood. That's ok, I still look for that feature, but meanwhile for saves to be placed in same directory as the binary is pretty good. Thanks again.

Just out of curiosity, what was the technical problem causing it to not work on stable distros?
I tried taking a look at the commit, but unfortunately could not understand too much...

Thanks again.