Sometimes the game crash when the player takes a berserk power up

[IsBebs]

Version of Crispy Doom: Daily build 5.6.3 20191203

Operating System and version: Windows 10 Home v1903

Game: Doom

Any loaded WADs and mods :
crispy-doom.exe -iwad DOOM.WAD -merge NEIS.wad -deh NEIS.deh

Bug description

Observed behavior:
Sometimes the game crashes when i take a berserk power up. If i restart and take same power up again, the game doesn't crash

[fabiangreffrath]

Oh! Could you try to narrow down when this happens? Does it only happen with NEIS.wad? Did you change sound settings or display size?

[IsBebs]

The game has crashed like this on other wads before
I noticed that the screen doesn't get red by the berserk when it crashes
here is the settings that i used when the crash occurred
[edit]changed picture 1 because color hud setting was wrong

[fabiangreffrath]

Does windows print anything when the game crashes? Any message?

[IsBebs]

Windows wrote this
message.txt
and created this text file when it crashed,
Report.txt

[fabiangreffrath]

Sigh, nothing relevant in these files.

Could you describe a bit more precise what happens? Do you hear the pick-up sound? Does the game crash immediately, or only after a few frames? Does the current weapon start to lower?

[turol]

Can you record a demo of your actions up to the crash? It doesn't actually have to be from a crashing run.

[IsBebs]

The pickup sound did play i think, the game then freezes for less than a second and then shuts down without any error messages.
I think the game freezes on the frame you pick up the berserk
I'm not sure if the weapon lowered or not
the crash happens very unexpectedly, I'm never prepared when it happens
i played for approximately one hour and don't remember exactly what i did,
so it's hard to recreate it
I have had this crash before and it feels like it always happen after i play for a while, but it's probably not relevant

I will record next time when the game crashes

Also excuse me for being poor with information, i should have shared this information from the very start

[SoDOOManiac]

I noticed that the pickup palette fades out too quickly, just blinks for a moment. Maybe that issue could be related?

EDIT: the behavior is the same in older versions, so most likely palette stuff is not the culprit.

[SoDOOManiac]

Any loaded WADs and mods :
crispy-doom.exe -iwad DOOM.WAD -merge NEIS.wad -deh NEIS.deh

@IsBebs This may be crash-prone, there is a DEHACKED patch inside NEIS.wad, so you should not load NEIS.deh separately (btw, where have you got the DEH for NEIS? It's not bundled separately...

[fabiangreffrath]

I noticed that the pickup palette fades out too quickly, just blinks for a moment. Maybe that issue could be related?

Is this in general or only related to this mod?

[SoDOOManiac]

Is this in general or only related to this mod?

In general. Though most likely it's a false alarm, I don't know how long the pickup palette should last, most likely it works properly as the behavior is the same in older versions.
Most likely the crashes were caused by applying the duplicate DEHACKED patch.

[IsBebs]

That's probably the problem, i loaded dehacked files without checking if they were in the wad.
@Zodomaniac i got the NIES with the deh file on https://www.doomworld.com/idgames/levels/doom/Ports/megawads/neis

[SoDOOManiac]

@IsBebs readmes are useful :) the NEIS readme says clearly:

Dehacked/BEX Patch : Yes (embedded in-wad; the external NEIS.deh is
only necessary for Vanilla/Chocolate Doom).

[IsBebs]

The game crashed again and the dehacked file wasn't loaded, so that wasn't the problem.
This time when the game crashed, the screen became red and played the sound, then it shut down without any message.
This is the parameters i used this time
crispy-doom.exe -iwad DOOM.WAD -merge NEIS.wad
I recorded with a save what i did to trigger the crash, it's a short demo because it was in the beginning of the level

crashDemo.zip

[IsBebs]

I made a recording where i recreated the crash, the movie file is to large so i share it through onedrive

https://1drv.ms/u/s!AvOwtFJjcRdZkmj_wNvjyWsKZCbg?e=TZisQT

[turol]

Does not crash under Linux, either playing the demo or manually loading the save and picking up the berserk. No errors under Valgrind either. I only tried a few times though, it looks like you had to do it a lot of times. Can you either find a more consistent way to manually reproduce or use some debugging tools yourself?

[SoDOOManiac]

@IsBebs, @turol, which version of DOOM.WAD are you using? I keep getting Crispy exiting with an error 'unknown tclass 66 in savegame'.

[IsBebs]

@Zodomaniac I'm using the ultimate Doom wad from the GOG version, it says that the version is 1.9
I don't think that my demo really is that helpful, the game didn't crash that time. I just did something similar to that time the game crashed. The problem is that the game doesn't save the demo when it crashes. I did the same thing in the video as in the demo, and the video shows when the game actually crashes.
I'm going to try to debug later to see if i can find the problem

[JNechaevsky]

Thread 1 received signal SIGSEGV, Segmentation fault.
V_DrawPatch (x=0, y=-312, patch=0x3ee4da0) at v_video.c:261
261             while (column->topdelta != 0xff)
(gdb)

[JNechaevsky]

...and again.

Thread 1 received signal SIGSEGV, Segmentation fault.
V_DrawPatch (x=2, y=179, patch=0x3750708) at v_video.c:261
261             while (column->topdelta != 0xff)
(gdb)

Edit: does not seems to be caused by 09efa6e, even after reverting to original P_MovePsprites, crash still happens with V_DrawPatch.

[JNechaevsky]

Interesting. After couple of attempts to reproduce it again, gdb suddenly gives me a couple of additional warnings:

I_Init: Setting up machine state.
OPL_Init: Using driver 'SDL'.
NET_Init: Init network subsystem.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - .....................................
P_Init: Init Playloop state.
S_Init: Setting up sound.
I_SDL_PrecacheSounds: Precaching all sound effects......................[New Thread 2424.0x1cc4]
[New Thread 2424.0x1954]
[Thread 2424.0x1954 exited with code 0]
[New Thread 2424.0xa94]
[New Thread 2424.0x13c0]
[New Thread 2424.0x10f8]
[New Thread 2424.0x1df0]
[New Thread 2424.0x13d4]
This is not a valid dehacked patch file!
IOperm_InstallDriver: Failed to start service (2).
I_InitSound: SDL audio driver is wasapi
S_ChangeMusic: D_INTROA (doom.wad)
S_ChangeMusic: D_E2M5 (doom.wad)
P_SetupLevel: E4M8 (NEIS.wad) Hard 0:00:00/0:00:00 Doom (BSP)
P_SpawnMapThing: Mapthing type 32000 without any skill tag at (35, -1769)
P_SetupLevel: E4M8 (NEIS.wad) Hard 0:00:00/0:00:00 Doom (BSP)
P_SpawnMapThing: Mapthing type 32000 without any skill tag at (35, -1769)
P_SetupLevel: E4M8 (NEIS.wad) Hard 0:00:00/0:00:00 Doom (BSP)
P_SpawnMapThing: Mapthing type 32000 without any skill tag at (35, -1769)
P_SetupLevel: E4M8 (NEIS.wad) Hard 0:00:00/0:00:00 Doom (BSP)
P_SpawnMapThing: Mapthing type 32000 without any skill tag at (35, -1769)
P_SetupLevel: E4M8 (NEIS.wad) Hard 0:00:00/0:00:00 Doom (BSP)
P_SpawnMapThing: Mapthing type 32000 without any skill tag at (35, -1769)
P_SetupLevel: E4M8 (NEIS.wad) Hard 0:00:00/0:00:00 Doom (BSP)
P_SpawnMapThing: Mapthing type 32000 without any skill tag at (35, -1769)

By looking into map in Doom Builder, MT type 32000 is "visual mode camera" (screenshot). AFAIR, this thing was used in versions of Doom Builder, 1.x for sure, and probably in some earlier 2.x, it keeps camera position of visual mode. Nowadays, camera position is saved in .dbs file.

I have deleted this thing, resaved whole NEIS.wad and tried again to reproduce this crash. After about ~100 attemps there were no crash. Could it be a key?

[fabiangreffrath]

@JNechaevsky Thanks for testing! Though, I don't think it has to do with this spurious map thing. After all, the fact that it has no skill level set means that it will never appear on the map. A crash in V_DrawPatch() probably means a bug in the status bar code. Does NEIS have a custom berserker box sprite? Could you probably type bt in the gdb window next time to see the backtrace to the crash?

[JNechaevsky]

1. Nope, there is no custom sprites, only status bar graphics STBAR, STARMS, and digits, which are seems to same in dimensions to original Doom and valid palette format.
   I also don't see any custom face backgrounds (STFB* and STPB*), but you are drawing it by using V_CopyRect, which have nothing common with V_DrawPatch, right?

2. Bingo! Have a look. There was no crash, but some random barely notable Tutti-frutti effect, instead of Bererk pack on the left.
   

Game is not crashing, I can change status bar size and weapons freely, but instead of black medikit, same colored pixels are appearing.

[JNechaevsky]

...a-a-and, bt:

Thread 1 received signal SIGSEGV, Segmentation fault.
V_DrawPatch (x=0, y=14733, patch=0x3748708) at v_video.c:261
261             while (column->topdelta != 0xff)
(gdb) bt
#0  V_DrawPatch (x=0, y=14733, patch=0x3748708) at v_video.c:261
#1  0x0045327d in ST_drawWidgets (refresh=refresh@entry=false)
    at st_stuff.c:1872
#2  0x004538cc in ST_diffDraw () at st_stuff.c:1971
#3  ST_Drawer (fullscreen=true, refresh=false) at st_stuff.c:1971
#4  0x004234bc in D_Display () at d_main.c:221
#5  0x00423625 in D_RunFrame () at d_main.c:513
#6  D_RunFrame () at d_main.c:478
#7  0x004236fd in D_DoomLoop () at d_main.c:575
#8  0x00424c4f in D_DoomMain () at d_main.c:2396
#9  0x00402a45 in SDL_main (argc=5, argv=0x30000) at i_main.c:77
#10 0x00402893 in main_getcmdline ()
#11 0x00402935 in WinMain@16 ()
#12 0x00468fdd in main (flags=5, cmdline=0xdb3418, inst=0xdb1d10)
    at E:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18

Well, my steps to reproduce:

• Download crashDemo.zip posted by @IsBebs and use savegame file from the archive.
• Load it as: gdb --args ./crispy-doom -iwad doom.wad -merge neis.wad
• Load saved game, pick up Berserk and other stuff about 15 times using game savegame reloading.
• Finally, pickup Berserk only and poof, crash happens.

[fabiangreffrath]

#1 0x0045327d in ST_drawWidgets (refresh=refresh@entry=false)
at st_stuff.c:1872

This only makes sense if the *patch pointer isn't pointing to the actual berserk box patch anymore. This, however, should be impossible, because the patch has been allocated with the PU_STATIC flag. So, it must have been changed to something like PU_CACHE during the course of the game.

Unfortunately, this issue is so rarely reproducible that I cannot really tell if the idea I have to fix this actually works. However, since this appears to be a memory management issue, it should be possible to increase the chances by forcefully decreasing the available memory size with a e.g. -mb 4 parameter.

The last remaining question, though, is what is so special about NEIS.wad that this issue appears there? Is the berserk box patch used in a texture so that its lump is only needed temporarily during texture composition and thus has its flag changed to PU_CACHE?

[IsBebs]

I tried the -mb 4 parameter
it makes the game crash every second time you pick a berserk pack
I also tried normal doom with the parameter on e2m2, it crashes there to, so i think it does not have to do with the neis.wad

[turol]

Still doesn't reproduce for me on Linux under Valgrind, with or without -mb 4. I do see the mapthing warnings though.

[fabiangreffrath]

Alright, I have found the cause!

First, steps to reproduce:

1. crispy-doom -iwad doom.wad -mb 4 -warp 22
2. Switch to Crispy HUD
3. IDCLEV22
4. Go ahead, turn left and pick up the Berserk kit
5. go to 3.

Repeat until it crashes. But, why does it crash?

If you pick up the Berserk kit the first time and have the Crispy HUD enabled, its sprite is shown as a patch in the bottom left corner of the screen. For this, the sprite lump is loaded with the PU_STATIC flag in ST_drawWidgets() and drawn with V_DrawPatch(). The *patch pointer points to the memory zone into which the patch lump was loaded. Now, if you load the level a second time, you start without the Berserk kit enabled. In order to pick one up, you'll have to run over it on the map.

However, in order for the Berserk kit to be rendered in the game scene, its sprite must be loaded into a "vissprite" in R_DrawVisSprite(). In the course of this, the sprite's patch is loaded with the PU_CACHE flag. This isn't a problem per-se. The patch is already loaded into zone memory, so the same pointer is returned as in the Crispy HUD case - but his time the memory zone's flag is changed to PU_CACHE. This means, this memory zone is purgeable whenever memory becomes sparse, and then it will be overridden with any other content. Consequently, the pointer in the Crispy HUD code path doesn't point to the intended patch lump anymore, although this has been loaded with the PU_STATIC flag.

[SoDOOManiac]

Congratulations @IsBebs on reporting and helping to track down a really obscure bug!
Other sprites of in-game objects that can be drawn in Crispy HUD are sprites of player gibs (when health is lower than -99), can the same kind of crash happen with them?