GZDoom crashes on Artix Linux

Need help running G/Q/ZDoom/ECWolf/Zandronum/3DGE? Did your computer break? Ask here.

Moderator: GZDoom Developers

GZDoom crashes on Artix Linux

Postby FalcN » Thu Dec 02, 2021 6:29 pm

I tried launching the latest GZDoom on Artix Linux and it keeps popping up with a Segmentation Fault error.

This is what I could find from the terminal:

Code: Select allExpand view
GZDoom g4.7.1-m - 2021-10-20 08:18:37 +0200 - SDL version
Compiled on Dec  2 2021

OS: Artix Linux, Linux 5.15.5-artix1-1 on x86_64
M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /usr/lib/gzdoom/gzdoom.pk3, 666 lumps
 adding /usr/lib/gzdoom/game_support.pk3, 2514 lumps
 adding /home/sam/.config/gzdoom/DOOM2.WAD, 2919 lumps
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
  Name: AMD Ryzen 3 2300X Quad-Core Processor
  Family 23 (23), Model 8, Stepping 2
  Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 F16C FMA3 BMI1 BMI2 HyperThreading
V_Init: allocate screen.
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
  Opened device Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital Stereo (HDMI 4)
  EFX enabled
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 126.05 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Using video driver x11
GL_VENDOR: AMD
GL_RENDERER: AMD Radeon RX 580 Series (POLARIS10, DRM 3.42.0, 5.15.5-artix1-1, LLVM 13.0.0)
GL_VERSION: 4.6 (Core Profile) Mesa 21.2.5 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.60

Max. texture size: 16384
Max. texture units: 32
Max. varying: 128
Max. combined shader storage blocks: 80
Max. vertex shader storage blocks: 16
Resolution: 640 x 480
Could not find patch set gzdoom.

Could not find patch set /usr/share/soundfonts/FluidR3_GS.sf2.

Could not find patch set /usr/share/soundfonts/FluidR3_GM.sf2.

ALSA lib pcm_dsnoop.c:600:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1035:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
ALSA lib pcm_dmix.c:1035:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock


*** Fatal Error ***
!!! Failed to exec debug process
Segmentation fault


Does anyone have a fix for this?
FalcN
 
Joined: 26 Sep 2020
Discord: 7241
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: GZDoom crashes on Artix Linux

Postby KynikossDragonn » Thu Dec 02, 2021 6:43 pm

You're probably going to want to make a backtrace with gdb or some such, but it looks like OpenALSoft is going haywire and none of the backends are properly able to access your sound device, and then I guess a null pointer dereference is happening as a result of this.

Do you have a .alsoftrc in your home directory? Are you running PulseAudio or Pipewire? If you're running Pipewire you need to also be starting pipewire-pulse after Pipewire itself starts.

For reference purposes this is the contents of my .alsoftrc file: (I'm using Pipewire)
Code: Select allExpand view
[general]
drivers = pulse
channels = stereo
sample-type = float32
frequency = 48000
period_size = 1024
periods = 2
stereo-mode = speakers
stereo-encoding = panpot
hrtf = false
resampler = bsinc24
sources = 1024
output-limiter = false
dither = false
volume-adjust = 0
default-reverb = None

[alsa]
device = pipewire
capture = pipewire

[pulse]
spawn-server = false
allow-moves = true
fix-rate = true
adjust-latency = false


If you don't use anything PulseAudio related but you use Pipewire you need to make sure Pipewire's ALSA plugins are properly installed, and set in the .alsoftrc file you only want the "alsa backend" by leaving "alsa" the only thing set in the "drivers" variable under [general]. OpenALSoft's pulse backend will work as well under Pipewire as long as you started the pipewire-pulse process. (pipewire-pulse is Pipewire's implementation of a PulseAudio server)
User avatar
KynikossDragonn
『霧雨魔理沙のペットドラゴン』
 
Joined: 12 Dec 2020
Location: Independence, KS, USA
Twitch ID: kynikossdragonn
Github ID: KynikossDragonn
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: Intel (Modern GZDoom)

Re: GZDoom crashes on Artix Linux

Postby FalcN » Thu Dec 02, 2021 6:57 pm

So what you're saying is, a dependency or driver might be missing? I'm pretty sure this is down to Artix being very different compared to baseline Arch because of it's use of OpenRC rather than systemd.
FalcN
 
Joined: 26 Sep 2020
Discord: 7241
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: GZDoom crashes on Artix Linux

Postby FalcN » Thu Dec 02, 2021 7:00 pm

How do I make a backtrace? I'm relatively new to this kinda shit so I don't really understand a lot of this.
FalcN
 
Joined: 26 Sep 2020
Discord: 7241
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: GZDoom crashes on Artix Linux

Postby KynikossDragonn » Fri Dec 03, 2021 6:08 am

FalcN wrote:How do I make a backtrace? I'm relatively new to this kinda shit so I don't really understand a lot of this.


Install "gdb" through whatever package manager Artix uses, then depending on if you installed GZDoom system wide (as root) or not you can either in a terminal type:

"$ gdb -q gzdoom"

or you'll need to switch to wherever gzdoom resides at and instead type

"$ gdb -q ./gzdoom"

When GZDoom segfaults, type "bt" in the terminal gdb is running from and press enter.

I've never used gdb manually myself, gzdoom is usually able to invoke it itself if it's already installed.
User avatar
KynikossDragonn
『霧雨魔理沙のペットドラゴン』
 
Joined: 12 Dec 2020
Location: Independence, KS, USA
Twitch ID: kynikossdragonn
Github ID: KynikossDragonn
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: Intel (Modern GZDoom)

Re: GZDoom crashes on Artix Linux

Postby Chris » Sat Dec 04, 2021 11:55 am

KynikossDragonn wrote:You're probably going to want to make a backtrace with gdb or some such, but it looks like OpenALSoft is going haywire and none of the backends are properly able to access your sound device, and then I guess a null pointer dereference is happening as a result of this.

OpenAL Soft seems to be initializing fine. A couple error messages about failing to get real-time priority on the mixing thread (fixed in OpenAL Soft's Git), but the device gets set up without issue. The later messages about not being able to load the patch sets and ALSA lib and JACK messages I think are coming from FluidSynth, which has been an annoyingly recurring problem. I don't know what's causing it here, though, so someone more familiar with the FluidSynth stuff will have to say.
User avatar
Chris
 
Joined: 17 Jul 2003


Return to Technical Issues

Who is online

Users browsing this forum: No registered users and 2 guests