Software renderer crashes on Linux

[Jan]

Gzdoom 3.0.0 on Linux crashes when I try to use the software renderer.

If I do the following:

Code: Select all

1. gzdoom -config gzdoom_new.ini
2. bring down console, type "vid_renderer 0" and quit
3. gzdoom -config gzdoom_new.ini
4. Start new game

It crashes with:

Code: Select all

*** Fatal Error ***
Segmentation fault (signal 11)
Address: (nil)

System: Linux ***** 4.9.25-1-lts #1 SMP Thu Apr 27 16:42:36 CEST 2017 x86_64 GNU/Linux

GZDoom version g3.0pre-107-g8303d8bbd (8303d8bbd14a77b74dc9a8ab9d9a00d9efcad1d6)
Compiler version: 6.3.1 20170306

Command line: /usr/lib/gzdoom/gzdoom -config gzdoom_new.ini

Wad 0: gzdoom.pk3
Wad 1: doom2.wad

Current map: map01

viewx = 1568.000000
viewy = 3168.000000
viewz = 97.000000
viewangle = 90.000000

Executing: gdb --quiet --batch --command=gdb-respfile-CdB0Rh

The title screen does load correctly in pixely software mode, but as soon as I try to start the game, it crashes. The same if I launch with -warp.

[Rachael]

What kind of OpenGL hardware do you have? It sounds like it was too old for the accelerated framebuffer and so it forced vid_hw2d to false - and as far as I know that does indeed cause a problem - not just in Linux.

[Jan]

What kind of OpenGL hardware do you have? It sounds like it was too old for the accelerated framebuffer and so it forced vid_hw2d to false - and as far as I know that does indeed cause a problem - not just in Linux.

I have a GeForce GTX 770

Software mode worked fine in 2.4.0 though, and it works fine in 3.0.0 with the windows binary (run under Wine though, as I have no real windows installation).

[Rachael]

Alright. I will take a look at this, but since I have no idea how to use a debugger on Linux, I may need some assistance at pinning this down from a Linux developer.

[_mental_]

Post complete crash log please.

[Jan]

Post complete crash log please.

Is this enough?

Code: Select all

*** Fatal Error ***
Segmentation fault (signal 11)
Address: (nil)

System: Linux ***** 4.9.25-1-lts #1 SMP Thu Apr 27 16:42:36 CEST 2017 x86_64 GNU/Linux

GZDoom version g3.0pre-107-g8303d8bbd (8303d8bbd14a77b74dc9a8ab9d9a00d9efcad1d6)
Compiler version: 6.3.1 20170306

Command line: /usr/lib/gzdoom/gzdoom -config gzdoom_new.ini -warp 01

Wad 0: gzdoom.pk3
Wad 1: doom2.wad

Current map: MAP01

viewx = 1568.000000
viewy = 3168.000000
viewz = 97.000000
viewangle = 90.000000

Executing: gdb --quiet --batch --command=gdb-respfile-SBXQj4
[New LWP 13859]
[New LWP 13860]
[New LWP 13861]
[New LWP 13900]
[New LWP 13915]
[New LWP 13977]
[New LWP 13978]
[New LWP 13979]
[New LWP 13980]
[New LWP 13981]
[New LWP 13982]
[New LWP 13983]
[New LWP 13984]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f377126b92a in waitpid () from /usr/lib/libpthread.so.0

* Loaded Libraries
From                To                  Syms Read   Shared Object Library
0x00007f377148ff40  0x00007f377154ce36  Yes (*)     /usr/lib/libSDL2-2.0.so.0
0x00007f377125f8e0  0x00007f377126d811  Yes (*)     /usr/lib/libpthread.so.0
0x00007f3771053fe0  0x00007f37710570ff  Yes (*)     /usr/lib/librt.so.1
0x00007f3770e3d4f0  0x00007f3770e4a327  Yes (*)     /usr/lib/libz.so.1
0x00007f3770bd5020  0x00007f3770c10570  Yes (*)     /usr/lib/libjpeg.so.8
0x00007f37709c26d0  0x00007f37709ce4a2  Yes (*)     /usr/lib/libbz2.so.1.0
0x00007f377077b0d0  0x00007f37707aa8a2  Yes (*)     /usr/lib/libgme.so.0
0x00007f3770570e20  0x00007f3770571ade  Yes (*)     /usr/lib/libdl.so.2
0x00007f3770273850  0x00007f37703230a9  Yes         /usr/lib/libstdc++.so.6
0x00007f376fedaec0  0x00007f376ff54cca  Yes (*)     /usr/lib/libm.so.6
0x00007f376fcc0a90  0x00007f376fcd08a5  Yes         /usr/lib/libgcc_s.so.1
0x00007f376f939b40  0x00007f376fa69a43  Yes (*)     /usr/lib/libc.so.6
0x00007f3771795b80  0x00007f37717b0f20  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007f3771958a50  0x00007f377196a536  Yes (*)     /usr/lib/libudev.so.1
0x00007f376f707580  0x00007f376f712b46  Yes (*)     /usr/lib/libresolv.so.2
0x00007f376f501560  0x00007f376f502d81  Yes (*)     /usr/lib/libcap.so.2
0x00007f376f2f9230  0x00007f376f2fda1e  Yes (*)     /usr/lib/libnss_compat.so.2
0x00007f376f0e3db0  0x00007f376f0efa01  Yes (*)     /usr/lib/libnsl.so.1
0x00007f376eed5ff0  0x00007f376eedc8b2  Yes (*)     /usr/lib/libnss_nis.so.2

Edit: Ah hang on, there's a lot more in the gzdoom-crash.log

I posted the full file here: https://www.dropbox.com/s/8a4h93bvez4n9 ... h.log?dl=0

[_mental_]

Did you build GZDoom from source code? If so, could you please try with Debug configuration?
Release one you are using lacks most of information because of optimization.
And as it works for me I'm asking you to do additional things in order to figure out what's wrong.

You can configure to a new directory and build debug version there, something like:

Code: Select all

cd gzdoom
mkdir debug
cd debug
cmake ..
make -j4

Then run GZDoom in gdb:

Code: Select all

gdb --args ./gzdoom -iwad doom2 +map map01

When it crashes execute bt command to get a callstack and post it here.

[Jan]

I am getting this:

Code: Select all

Thread 1 "gzdoom" received signal SIGSEGV, Segmentation fault.
0x00000000009b0f14 in OpenGLSWFrameBuffer::OpenGLPal::Update() ()
(gdb) bt
#0  0x00000000009b0f14 in OpenGLSWFrameBuffer::OpenGLPal::Update() ()
#1  0x00000000009b17c0 in OpenGLSWFrameBuffer::OpenGLPal::OpenGLPal(FRemapTable*, OpenGLSWFrameBuffer*) ()
#2  0x00000000009b1875 in OpenGLSWFrameBuffer::CreatePalette(FRemapTable*) ()
#3  0x0000000000a41177 in FRemapTable::GetNative() ()
#4  0x00000000009ac756 in OpenGLSWFrameBuffer::SetStyle(OpenGLSWFrameBuffer::OpenGLTex*, DrawParms&, unsigned int&, unsigned int&, OpenGLSWFrameBuffer::BufferedTris&) ()
#5  0x00000000009b3658 in OpenGLSWFrameBuffer::DrawTextureParms(FTexture*, DrawParms&) ()
#6  0x0000000000933add in DCanvas::DrawChar(FFont*, int, double, double, int, int, ...) ()
#7  0x0000000000978234 in DBaseStatusBar::DrawString(FFont*, FString const&, double, double, int, double, int, int, bool, int, int) ()
#8  0x000000000097893a in ?? ()
#9  0x0000000000aad0b7 in VMExec_Unchecked::Exec(VMFrameStack*, VMOP const*, VMReturn*, int) ()
#10 0x0000000000aaef77 in VMExec_Unchecked::Exec(VMFrameStack*, VMOP const*, VMReturn*, int) ()
#11 0x0000000000abbcec in VMCall(VMFunction*, VMValue*, int, VMReturn*, int) ()
#12 0x0000000000976fe0 in DBaseStatusBar::CallDraw(EHudState) ()
#13 0x0000000000767753 in D_Display() ()
#14 0x0000000000767b44 in D_DoomLoop() ()
#15 0x00000000007693ba in D_DoomMain() ()
#16 0x000000000052bd62 in main ()

Oh, and for the record:
- The source I am using is from git commit 8303d8bbd14a77b74dc9a8ab9d9a00d9efcad1d6.
- The Arch PKGBUILD script has some more cmake options, which I have included in the debug build as well:

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_FLAGS="$CFLAGS -DSHARE_DIR=\\\"/usr/share/gzdoom\\\"" \
-DCMAKE_CXX_FLAGS="$CXXFLAGS -DSHARE_DIR=\\\"/usr/share/gzdoom\\\"" \
-DCMAKE_EXE_LINKER_FLAGS="$LDFLAGS -Wl,-z,noexecstack" \
-DCMAKE_INSTALL_PREFIX=/usr \
-DINSTALL_PATH=lib/gzdoom \
-DINSTALL_PK3_PATH=share/gzdoom \
..  

Shell variables $LDFLAGS $CFLAGS and $CXXFLAGS are empty, so they shouldn't have any effect.

[_mental_]

This is the same as before because of -DCMAKE_BUILD_TYPE=Release. Remove this option or explicitly change Release to Debug.

[Jan]

This is the same as before because of -DCMAKE_BUILD_TYPE=Release. Remove this option or explicitly change Release to Debug.

Well this is awkward ... it doesn't crash when I change it to -DCMAKE_BUILD_TYPE=Debug

[Chris]

What if you use '-DCMAKE_BUILD_TYPE=RelWithDebInfo'?

[Jan]

What if you use '-DCMAKE_BUILD_TYPE=RelWithDebInfo'?

Still doesn't crash then.

[dpJudas]

Usually such a behavior is the sign of an uninitialized variable. Any easy way to make it fuzz memory on Linux?

[_mental_]

Strange that crashes specific to Release configuration (using -O3 compiler option in particular) happen with GCC built executables only.
Clang is fine, MSVC with full optimization is fine too. There were some troubles with -Ofast (in Clang at least, I didn't check in GCC) although this option is quite unpredictable.
LTO/LTCG builds with any compiler I tried crash on startup but it's totally different issue.

[dpJudas]

An error in the compiler is of course always an option, but otherwise it could be an uninitialized variable, a buffer overrun, or a race condition. The call stack pretty much rules out a race condition (no threads in this part).

That it works with clang and msvc doesn't have to make it a compiler error because there's still the chance that different memory layouts might have prevented a buffer overrun from crashing the application in the clang case.