Raze 1.8pre-208-g316867581, Out of memory kill and system freeze

[jwrich82]

I have an issue of wild memory usage and CPU spike that causes Oout of Memory reaper to kick in and kill raze
link to forum post viewtopic.php?p=1239129#p1239129

Previously I had Arch Linux running using the script created by MatMoul (archfi) to install it with

KDE Desktop as environment, ALS as the audio backend

I tried using the AUR package with 'yay -S raze'
Everything freezes and eventually frees up when using the release build there.

I followed the ZDoom wiki in building raze myself

Code: Select all

git clone https://github.com/ZDoom/Raze.git
cd Raze
mkdir build

a='' && [ "$(uname -m)" = x86_64 ] && a=64
c="$(lscpu -p | grep -v '#' | sort -u -t , -k 2,4 | wc -l)" ; [ "$c" -eq 0 ] && c=1
cd ~/Raze/build &&
rm -f output_sdl/liboutput_sdl.so &&
if [ -d ../fmodapi44464linux ]; then
f="-DFMOD_LIBRARY=../fmodapi44464linux/api/lib/libfmodex${a}-4.44.64.so \
-DFMOD_INCLUDE_DIR=../fmodapi44464linux/api/inc"; else
f='-UFMOD_LIBRARY -UFMOD_INCLUDE_DIR'; fi &&
cmake .. -DCMAKE_BUILD_TYPE=Release $f &&
make -j$c

moved the raze and raze.pk3 to a directory ~/raze

in ~/raze created a 'run.sh' with the following contents

Code: Select all

#!/bin/bash
./raze -config ./config.ini

under ~/raze, created a directory 'data' and placed DUKE3D.GRP in the folder.

set the 'run.sh' as executable and executed it.
System locks up (with or without swap on, the only difference is length of time the freeze happens before the reaper kills it)

I follow the same steps, this time, building a debug version

Code: Select all

a='' && [ "$(uname -m)" = x86_64 ] && a=64
c="$(lscpu -p | grep -v '#' | sort -u -t , -k 2,4 | wc -l)" ; [ "$c" -eq 0 ] && c=1
cd ~/Raze/build &&
rm -f output_sdl/liboutput_sdl.so &&
if [ -d ../fmodapi44464linux ]; then
f="-DFMOD_LIBRARY=../fmodapi44464linux/api/lib/libfmodex${a}-4.44.64.so \
-DFMOD_INCLUDE_DIR=../fmodapi44464linux/api/inc"; else
f='-UFMOD_LIBRARY -UFMOD_INCLUDE_DIR'; fi &&
cmake .. -DCMAKE_BUILD_TYPE=Debug $f &&
make -j$c

Same problems.

I have reisntalled Arch Linux, using archfi (archfi.sf.net/Archfi)
I selected linux (no LTRS or Zen build)
KDE Plasma as chosen desktop environment, gtreamer backend with ALSA.
same steps, release build and debug build. Same problems.

KDE Plasma as chosen desktop environment, vlc backend with ALSA.
same steps, release build and debug build. Same problems.

KDE Plasma as chosen desktop environment, vlc backend with pipewire.
same steps, release build and debug build. Same problems.

I am tired of rebuilding linux now, I have gone back to a clean install of KDE Plasma, gstreamer and pipewire

I am not getting any log dumps, unless I am not looking in the right places. ~/.config/raze keeps creating grpcrccache.txt and raze.log (txt and log included form most recent trial), with no changes and doesn't matter if I use release or debug.

Is there a switch on the debug that I need to include in my run.sh? is the debug log when running the debug version being spit out somewhere else?

With my limited knowledge of Linux, it might be my CPU???

CPU i5-660k (no overclock) (microcode loaded)
RAM 16GB DDR4-2400 CL14
GPU MSI GAMING X Radeon RX 580 8 GB (open amdgpu driver)

Possible bug? What is needed from me to track this down?

[mjr4077au]

No idea off hand, but a Windows 11 in-place upgrade erased all my UEFI boot entries and I haven't repaired them for my Arch install. I'll try to get something working there this week and see if I can reproduce.

[Graf Zahl]

I've never seen any kind of large memory leak on the Windows builds so this is a bit puzzling. What's the experience of other Linux users here?
One thing that may not be overlooked is that Linux links lots of external libraries where we have no control over which version is being used. We cannot rule out some bad interaction here.

[jwrich82]

I am trying to remember the command that displays a program's library calls... I will have to dive into a very old issue I had with a different program and completely unrelated issue.
Unless there is some BIG departure form ZDoom with Raze, I have yet to have a problem with GZDoom based mods, TCs, whole new games built off them like the games on Steam. I haven't had a problem with other games on different engines, whether they are native Linux executable, through WINE or Proton...it is very odd. eduke32, latest build works fine. Better than I would expect anyway. If I can find that library bit, I'll update this post.

And that, didn't take long.

Code: Select all

 ldd "./raze" 

Code: Select all

linux-vdso.so.1 (0x00007ffd7edd3000)
        libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007fb03dc29000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fb03fbae000)
        libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fb03fb2b000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fb03fb18000)
        libvpx.so.8 => /usr/lib/libvpx.so.8 (0x00007fb03d800000)
        libzmusiclite.so.1 => /usr/lib/libzmusiclite.so.1 (0x00007fb03d64e000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fb03d400000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fb03db41000)
        libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007fb03facd000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fb03faad000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fb03d219000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fb03fbf2000)
        libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007fb03d193000)
        libmpg123.so.0 => /usr/lib/libmpg123.so.0 (0x00007fb03dae4000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0x00007fb03d0a5000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fb03cf5a000)
        libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007fb03ceaf000)
        libFLAC.so.12 => /usr/lib/libFLAC.so.12 (0x00007fb03ce6c000)
        libopus.so.0 => /usr/lib/libopus.so.0 (0x00007fb03ce12000)
        libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0x00007fb03cd9a000)
        libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007fb03fa7b000)
        libogg.so.0 => /usr/lib/libogg.so.0 (0x00007fb03dad9000)
        libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007fb03ccff000)

What I don't know is how to track down if one of these libraries is the problem or what. I have also been talking to the folks on Arch Linux forum and they aren't going to be able to help until I am known to be at a base Arch Linux build, meaning no "easy install scripts" like Archfi or a distribution based on Arch Linux. So, for the next few hours, I might be biting the bullet and build Arch from scratch. It might take me a bit.

[Chris]

You can try running with strace. which will print out kernel calls being made by the process for things like read and mmap (strace ./raze). If you enable debug logging with Raze while doing that (piping the output to a log file or something), it may help narrow down where and what is causing too much memory to be used.

[jwrich82]

As far as I know, I have a debug build, and I cannot figure out the commands to get it to either self log itself, or give a more detailed log.

After complete reinstall, new /home with no remnants of the previous installs, using no scripts and working with JUST the Arch wiki from step 1 to desktop environment, I still have the same problem. I am putting together some scripts and programs to try and hunt down the possible problem.

[CandiceJoy]

Have you tried the DRDTeam Raze dev build? I'm curious if it's a problem in the build or the code. My dev builds are built somewhat differently, so it might could shed some light on the situation, at least. https://devbuilds.drdteam.org/raze-linux/

[mjr4077au]

Have you tried the DRDTeam Raze dev build? I'm curious if it's a problem in the build or the code. My dev builds are built somewhat differently, so it might could shed some light on the situation, at least. https://devbuilds.drdteam.org/raze-linux/

Any chance you could please fix up the Windows builds? They're having a bit of a sad

[jwrich82]

I'll look into one of those builds.

Another consideration was brought to my attention. I am on Arch Linux, using systemd-bootloader, SDDM and Plasma on Xorg/X11. I was told I might want to test it on Wayland. Might be the way Raze is setup to handle memory and such.
Is anyone else on Linux and using Wayland?

UPDATE

Alrighty. So, I tried the pre-built builds on DRD.
I first tried raze-linux-x64-1.8pre-208-g316867581.tar.xz as it looks like the version I recently built. It still failed. Memory and CPU spike with sudden system freeze, after some time, control returned to me as OOM Reaper killed the process.

Next, I decided to go to the last point build. raze-linux-x64-1.7pre-469-gcfef8c8a7.tar.xz for Apr 08 2023 22:07:47. It ran fine! I have yet to stress it by using high-res mods and such, but it ran! Smoothly. I played first level of Duke Nukem with no issues.

To try and track down when the "break" occurred, I then tried raze-linux-x64-1.8pre-127-g684fb5eb74.tar.xz on Apr 09 2023 11:13:0. Failed. Same issues as the 1.8pre builds.

So, this tells me between raze-linux-x64-1.7pre-469-gcfef8c8a7 and raze-linux-x64-1.8pre-127-g684fb5eb7, something changed to cause the issue. I can't run the equivalent Windows build as I do NOT dual boot between Windows and Linux.

I also started looking at the releases listed on github.
So far in my testing;
1.7.1, 1.7.0 do the same things that the non-working dev builds were doing.
1.6.2 seems to be running just fine.

[Graf Zahl]

There have been multiple reports for this already. Closing as a duplicate.