Linux build crashes

[dsdman]

hyper3DGE git build (latest commit as of 01/13/18). Running Arch linux kernel 4.14.13. i7 4720hq processor, nvidia gtx 960m, and 16 gigs of ram. I have all dependencies installed.

While hyper3DGE compiles just fine, running the binary does nothing.

Steps to reproduce:

1. Compile hyper3DGE (I used the cmake build system)
2. copy over 'data' directory to directory with binary
3. copy over any iwads/pwads (ie DOOM2.WAD)
4. ./3DGE -iwad DOOM2.WAD
5. Expected behavior: doom 2 runs.
6. Actual behavior: nothing happens (no error messages or the like given)

I have also tried ./3DGE -ddf doom_ddf -iwad DOOM2.WAD with the same results.
Thanks again.

[gameblabla]

This is something i can confirm. Using GDB with debug symbols does not lead to anything. (other than the fact the driver crashed)
0x00007fffec417878 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so

This happens with both nouveau and llvmpipe. Last time i tried last month, it was also crashing.
I thought they would figure this out but guess not... It used to work so i'll try to bisect it and see what's going on.

[gameblabla]

Ok, so i discovered the commit that makes the Linux build crash.
It's this one :
97efa22
If you uncomment RGL_GL3Enabled in the file src/hu_draw.cc at line 682, it will work properly.

Seems like Renderbuffers does not work properly on Linux... Or maybe the code is not compliant.
@Corbachu, why was this uncommented ?

[Corbachu]

@gameblabla there's a command-line switch called -norenderbuffers. Use that, and the game should start.

Anyways, I made further GLSL shader path fixes (though shaders right now, while they now compile from path/file, still need to get the screen quad set up beforehand) that should get the game started. Please retry and let me know if it is fixed.

[dsdman]

@Corbachu I have tried the new build (commit 9fc9260) and it is still failing to launch doom. I have tried with and without the -norenderbuffers option, both without success.

I am using the latest proprietary linux nvidia drivers (387.34). In addition to this, the windows build of hyper3DGE (2.1.0 test 3) runs just fine in linux through wine. Lasty, other doom ports like gzdoom (tested a couple of days ago) compile and run just fine. Hope that helps.

EDIT: Also commit 59aaf38

[Corbachu]

@dsdman Have you tried the newest revision?? Made some big changes..try it out. If it still fails then it might be a driver related issue.

[dsdman]

@Corbachu currently testing the newest revision. There is a build error on line 271 of con_main.cc due to a function call to '_strupr', which seems to be a part of the Microsoft C library (probably not supported in GNU gcc/g++, hence the build error). It compiles if you comment out the line or change it to strdup.

Once compiled, it still doesn't run Doom, so it may be some kind of proprietary Nvidia driver issue with linux, although I have no idea how to confirm if this is the case or not. When I try to debug it using gdb, it claims that the program exited normally.

[Corbachu]

@dsdman What does your Debug.txt contain? That would help me figure out what is going wrong, specifically the OpenGL settings. If it turns out GLSL isn't supported or working right, than it might be the cause. Also, the program should be calling I_Error, not just exiting normally, so that makes me think some sort of OpenGL Extension is mucking stuff up.

Try recompiling with the DEBUG pre-processor, and you could even use DEVELOPERS. Usually I use those if I need a little more information about what is going on that can't normally be provided otherwise. And, just if it helps, I also use the pre-processor flag NDEBUG.

[OrdinaryMagician]

So, I tried my hand at this and I found something rather amusing.

On Linux, E_Main is never called from main. That's... a rather big oversight.

Technically, this is not a crash, it just exits cleanly.

[dsdman]

@Corbachu I have recompiled with "-DDEBUG -DDEVELOPERS -DNDEBUG" added to the definitions in CMakeLists, but there seems to be no 'Debug.txt' generated when I run hyper3dge (I can confirm that the preprocessors are being passed if I enable VERBOSE when compiling). I do however have the output of gdb log file:

`Breakpoint 1 at 0x10e555: file /home/dylan/apps/src/hyper3DGE/src/system/i_main.cc, line 1.
Starting program: /home/dylan/apps/src/hyper3DGE/bin/3DGE -iwad DOOM2.WAD
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, main (argc=3, argv=0x7fffffffea18) at /home/dylan/apps/src/hyper3DGE/src/system/i_main.cc:64
64 bool allow_coredump = false;
65 for (int i = 1; i < argc; i++)
66 if (strcmp(argv[i], "-core") == 0)
0x00007ffff54269e0 in strcmp_ifunc () from /usr/lib/libc.so.6
Single stepping until exit from function strcmp_ifunc,
which has no line number information.
0x00007ffff54d3670 in __strcmp_ssse3 () from /usr/lib/libc.so.6
Single stepping until exit from function __strcmp_ssse3,
which has no line number information.
main (argc=3, argv=0x7fffffffea18) at /home/dylan/apps/src/hyper3DGE/src/system/i_main.cc:65
65 for (int i = 1; i < argc; i++)
66 if (strcmp(argv[i], "-core") == 0)
65 for (int i = 1; i < argc; i++)
69 I_SetupSignalHandlers(allow_coredump);
I_SetupSignalHandlers (allow_coredump=false) at /home/dylan/apps/src/hyper3DGE/src/system/unx/unx_system.cc:146
146 signal(SIGPIPE, I_SignalHandler); // CPhipps - add SIGPIPE, as this is fatal
148 if (allow_coredump)
155 signal(SIGSEGV, I_SignalHandler);
156 signal(SIGTERM, I_SignalHandler);
157 signal(SIGILL, I_SignalHandler);
158 signal(SIGFPE, I_SignalHandler);
159 signal(SIGILL, I_SignalHandler);
160 signal(SIGINT, I_SignalHandler); // killough 3/6/98: allow CTRL-BRK during init
161 signal(SIGABRT, I_SignalHandler);
162 }
main (argc=3, argv=0x7fffffffea18) at /home/dylan/apps/src/hyper3DGE/src/system/i_main.cc:77
77 I_CheckAlreadyRunning();
I_CheckAlreadyRunning () at /home/dylan/apps/src/hyper3DGE/src/system/unx/unx_system.cc:167
167 }
main (argc=3, argv=0x7fffffffea18) at /home/dylan/apps/src/hyper3DGE/src/system/i_main.cc:143
143 return 0;
145 }
0x00007ffff53c1f4a in __libc_start_main () from /usr/lib/libc.so.6
Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 8365) exited normally]
`

Judging from this, it seems to be that @OrdinaryMagician might be right about E_Main not being called, as it seems to never leave i_main.cc.

[dsdman]

UPDATE: I have now got the program to run by adding:

#ifdef LINUX
try {
E_Main(argc, (const char **) argv);
//common_main(argc, argv);
}
catch (int e) {
I_Error(0, "Exception caught in main: see CRASHLOG.TXT for info\n");
}
#endif

below line 142 (just below the WIN32 ifdef). I then had to add edge.epk from the windows build (seems to be missing from data.) Now the program runs, but there are no graphics (no menu, no game graphics) sounds seem to work just fine.

EDIT: Here is the output of the program.
log.txt

EDIT2: I have found both 'Debug.txt' and 'edgegl.txt' in my home directory (~/.EDGE2) while doing something else. Here they are:
debug.txt
edgegl.txt is empty.

[Corbachu]

@dsdman Go ahead and commit your changes for the other Linux users, if you can, I appreciate it :-) @OrdinaryMagician thank you so much for looking into it <3

Enable edgegl.txt output, I forget where I had it ifdefed (at work ATM), but its used to show if the shaders have been compiled and read successfully. Also try running again with -norenderbuffers.

[Corbachu]

@dsdman, marking as resolved - for missing display, open another issue so we can track it, thanks again! :-)

[ryan-sg]

hehe this bit me (i'm baaack! ;) Same issue hits me on OpenBSD, but many things have changed since I last was involved. I'll try and make some neat little pull requests shortly....