Linux: ZScript can break DEHACKED parser

[MartinHowe]

In some circumstances loading a ZScript lump can break the DEHACKED parser even if the ZScript lump does not refer to the actors modified by DEHACKED. Happens with 4.9.0 and 4.10.0. I was playing through Urbanside with my Black Cats mod loaded.

When GZDoom tries to load the DEHACKED lump in Windows (Win 10 22H2 in VMWare Player 17 with all updates) it works fine. In any Linux version (self-build, official from the repo, portable) it provokes this: Bad numeric constant 0 for Bits. This is on Linux Mint 21, which is an Ubuntu derivative. The actors DEHACKED tries to modify (by thing number) are 96 (small green torch) and (129) one of the hanging dead bodies; Black Cat does nothing at all with these and I cannot see how it would affect them. I didn't notice it until MAP04, as the map uses these actors as rainfall graphics by changing the sprites and setting the SOLID bit to zero. It doesn't matter whether blackcat.pk3 appears before urbanside on the command line or after it. If I can get time at work during breaks today I will test it in a bare-metal Windows installation, but suspect it will make no difference.

As to providing a cut down example, I have no idea where to start. Black Cat is 3000+ lines of non-comment code last time I checked and heavily interdependent. I will give it a go but need guidance from the devs on what areas to focus on or what ZScript functionality I could try to code in order to provoke it happening in a smaller case.


FWIW, details below (should any further info be required, ask me for it):

Code: Select all

martin@luna:~/Downloads/urbanside$ file /usr/games/gzdoom/gzdoom
/usr/games/gzdoom/gzdoom: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=df58b1f847c985305bf762f20438f93eaa40ec7c, for GNU/Linux 3.2.0, stripped

Code: Select all

martin@luna:~/Downloads/urbanside$ /usr/games/gzdoom/gzdoom -iwad doom2 -file blackcat.pk3 urbanside.wad -warp 04
GZDoom 4.10.0 - 2022-12-04 15:23:05 +0100 - SDL version
Compiled on Dec  4 2022

OS: Linux Mint 21, Linux 5.15.0-56-generic on x86_64
GZDoom version 4.10.0
W_Init: Init WADfiles.
 adding /usr/games/gzdoom/gzdoom.pk3, 672 lumps
 adding /usr/games/gzdoom/game_support.pk3, 2559 lumps
 adding /usr/share/doom2/doom2.wad, 2919 lumps
 adding /usr/games/gzdoom/game_widescreen_gfx.pk3, 214 lumps
 adding blackcat.pk3, 262 lumps
 adding urbanside.wad, 1576 lumps
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
  Opened device Built-in Audio Analogue Stereo
  EFX enabled
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
  Family 6, Model 60, Stepping 3
  Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 F16C FMA3 BMI1 BMI2 HyperThreading
V_Init: allocate screen.
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 146.59 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
Adding dehacked patch urbanside.wad:DEHACKED
Bad numeric constant 0 for Bits
Bad numeric constant 0 for Bits
Patch installed
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: NVIDIA Corporation
GL_RENDERER: NVIDIA GeForce GT 1030/PCIe/SSE2
GL_VERSION: 4.6.0 NVIDIA 515.86.01 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.60 NVIDIA

Max. texture size: 32768
Max. texture units: 32
Max. varying: 124
Max. combined shader storage blocks: 96
Max. vertex shader storage blocks: 16
Resolution: 1920 x 1080

----------------------------------------

MAP04 - Rooftops of Diluvio

[Player701]

I have no way to test this, but today I've had some time to look at the source code, and I can see that the DeHackEd parser uses errno to check for a possible error after trying to parse a number. (see relevant lines in d_dehacked.cpp.) I suspect the problem is that on some platforms (like Linux) errno is not reset on success, and some code in the ZScript parser leaves it at ERANGE. Then it gets picked up by the DeHackEd code, which triggers the error. I guess fixing this should involve resetting errno to 0 before calling strtoll.

[Graf Zahl]

The real fix should be to discontinue using errno. This is the kind of error check from hell, conceived at a time where safe programming was an alien concept.
The code also simply was wrong. You are supposed to check if an error occured before checking errno.

[Player701]

Quite true.