Arch Linux, Raze and Duke atomic edition crashing system

[jwrich82]

First, my specs:
CPU i5-660k (no overclock)
RAM 16GB DDR4-2400 CL14
GPU MSI GAMING X Radeon RX 580 8 GB
OS Arch Linux, fully up to date as of writting

So. I follow the setup, under ~/.config/raze, I make a folder 'data', I put DUKE2D.GRP into it. From terminal, I enter 'raze' and hit enter. It begins to run and spits out some messages, a couple warnings about "raze.pk3:zscript/games/duke/actors" flamethrower, firefly and bowling. Compiling: 'game.con'. * WARNING.(GAME.CON, line 3330) Expected an identifier, got a numeric literal 1. Then a few more lines and "Resolution: 640 x 480"
System freezes. Completely. Mouse doesn't move. I can't open another TTY and reboot the system, I have to psychically power cycle my computer.

I have attache both the log and grpcache created in the raze config folder.

GZDoom games play without ANY complaint whatsoever. I also followed the wiki's info on building GZDoom and have all the dependencies it states it needs when building from source.
Anything else needed?
Anyone else have this issue and found a fix?

Edit, just ensured everything installed is up to date. Still, same behavior and as far as I can see, no difference in the logs.

I just tried it again, this time with Blood. Same thing. This time, an INI wasn't generated in the 'data' folder.
Also of note, I let it just sit. Previously, I would reboot after one or two minutes of nothing happening. After about 5 minutes, the terminal window crashed and closed, the system now responsive with no seeming issues running in the background, but Blood did not start. I am going to setup Duke 3D again and see what happens. I am following viewtopic.php?t=71962 on how to setup, in case people are wondering.

And with both Blood and Duke 3D, same thing. As for the ini, it looked like it was generated when I ran raze without selecting an IWAD as I closed all open programs before I selected either game.

5 minutes of system freeze, then terminal window closes. The line by line readout is what is in the log, minus the GL_* lines.

[Chris]

5 minutes of system freeze, then terminal window closes. The line by line readout is what is in the log, minus the GL_* lines.

I've had system freezes like that (not from Raze, but generally speaking) as a result of running out of memory (both physical and swap). Linux has a rather obscure bug where sometimes when memory gets exhausted, it'll enter this painfully slow loop of swapping things in and out of RAM while trying to run the OOM killer, during which time the system becomes unresponsive. It can take minutes (and in extreme circumstances, tens of minutes) for it to actually kill the offending process and let the system continue. It doesn't happen all the time, it seems to affect certain users more than others, and some never see the problem even when trying to trigger it.

You say you have 16GB of RAM, which does make me question of this is the issue since it shouldn't use much memory at all, but the symptoms do line up. Unless you have a bunch of RAM hungry things running in the background with little or no swap, perhaps there's a bug somewhere causing Raze to allocate way much more memory than it's supposed to.

[jwrich82]

Yeah. 16GB and this only happens when I run Raze. I've done some resource heavy video editing... no lockup. Three Windows 10 VMs running, using 4GB each... no lockup. The only thing I have running in the background other than KDE Plasma is Munt and Steam (keeping my 8bitdo controller from reconnecting and rumbling every few seconds).

I'll look at my swap and make sure it is good to go.

EDIT
Now I am wondering if I should report a bug... or at least look a the opened bugs. I disabled swap and tried running Raze again. This time, the only change is terminal shuts down in only 30 seconds. Or just try to run a log capture of some sort. The log spit out by raze is useless as far as I can tell unless some kind of more in depth log is generated by a switch or something.

[Chris]

Something to look at would be to have System Monitor or htop or something running when you try to launch Raze and see what memory usage gets to be like before it freezes. And after Raze dies, you can check dmesg to see if the OOM killer was invoked or otherwise why the process was killed.

[jwrich82]

And you, my friend...are correct. CPU usage and memory usage (swap file on) goes through the roof. and out of memory reaper kicks in and kills it. Happens faster with page file off.

Damn. I hope I don't have to go through the process of rebuilding Arch. I'll poke around the Arch forums and see what I can find. I have never experienced this before until Raze.

[jwrich82]

Well, I completely reinstalled Arch.
With JUST the duke3d.grp under /data
raze 1.7.0-1 -> Same memory and CPU spike and eventual kill by OOM reaper.
raze 1.8pre+167+g17cde1e3c-1 -> same as above.
With or without swap on, still the same problems.

I might try and build from a direct github pull and see what happens. Looks like the AUR is a step behind.

EDIT
Yup, even on latest github pull (outline din the zdoom wiki for building gzdoom) it does the same thing.

Should I go ahead and put this up as a bug or just wait for raze to mature more? the later option doesn't seem to be productive as it looks like no one else on Linux is having my problem.

[Chris]

I'd report it as a bug. If possible, try to make a debug build and see if you can get any information about what the game's doing at the time of the memory spike (I'm not too familiar with Raze, so unfortunately I can't help much with that).