[Bug] Signal 11 crash with "Stickney Installation"

NightFright2k19 commented 2 years ago

On E1M2 of "Stickney Installation", you get a crash to desktop with the following message after strafe-running across a slime pool with some platforms:

"I_Signalhandler: Exit on illegal storage access (Signal 11)"

Used Woof release: Latest Win64 workflow snapshot from "Master" branch (3046909730)

To reproduce:

Load attached savegame
Strafe-run across the slime pool ahead of you with the platforms
Crash will eventually happen, but not every time (most reliably when trying to strafe-run right after loading the savegame)

Notes:

This can also happen later on if you skip this section, in any other part of the map.
I ran the pwad with Boom compatibility as menu default, but -complevel 2 as startup parameter, like this: woof.exe -iwad "../../iwad/doom.wad" -file "../../pwad/doom/stickney.wad" -complevel 2

The attached zipfile contains:

The actual pwad (stickney.wad)
Savegame (woofsav0.dsg)
My config file (woof.cfg)
Recorded demo of the incident (stickney.lmp)

stickney_test.zip

fabiangreffrath commented 2 years ago

Very good bug report, thank you! Nevertheless, I cannot reproduce this issue with my 64-bit Linux build, even though precisely following your detailed instructions. Do you have anything in your autoload directories that might cause trouble?

NightFright2k19 commented 2 years ago

I have some files in my autoload dirs, but they are purely cosmetic and shouldn't have any major impact on gameplay. I am attaching all files to make a 100% identical testing environment possible.

Included are:

autoload/doom.wad: d1spfx20.wad (sprite fixes) doom1wide.wad (widescreen gfx) greencross.wad (replacement for red crosses on medikits)
autoload/doom-all.wad: bloodcolor.deh (blood color fixes) bmap_fix.wad (fixes for some brightmaps) perk_sfx.wad (Per Kristian's Doom sounds)

autoload_test.zip

rfomin commented 2 years ago

I reproduce it, it crashes for me right on woofsav0 load. Backtrace:

00 0000001d`dcb1eb50 00007ff6`bf3a0505     woof!R_InterpolateTextureOffsets+0x91 [C:\develop\woof\src\p_spec.c @ 2679] 
01 0000001d`dcb1eba0 00007ff6`bf3039dd     woof!R_RenderPlayerView+0x225 [C:\develop\woof\src\r_main.c @ 821] 
02 0000001d`dcb1f4d0 00007ff6`bf3075f3     woof!D_Display+0x24d [C:\develop\woof\src\d_main.c @ 285] 
03 0000001d`dcb1f560 00007ff6`bf323728     woof!D_DoomMain+0x1433 [C:\develop\woof\src\d_main.c @ 2681] 
04 0000001d`dcb1f630 00007ff6`bf3f8f62     woof!SDL_main+0x68 [C:\develop\woof\src\i_main.c @ 130] 
05 0000001d`dcb1f660 00007ff6`bf3f6539     woof!main_getcmdline+0x132 [C:\projects\SDL\src\main\windows\SDL_windows_main.c @ 82] 
06 0000001d`dcb1f6c0 00007ff6`bf3f63de     woof!invoke_main+0x39 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 79] 
07 0000001d`dcb1f710 00007ff6`bf3f629e     woof!__scrt_common_main_seh+0x12e [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
08 0000001d`dcb1f780 00007ff6`bf3f65ce     woof!__scrt_common_main+0xe [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331] 
09 0000001d`dcb1f7b0 00007ffc`59d07034     woof!mainCRTStartup+0xe [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp @ 17] 
0a 0000001d`dcb1f7e0 00007ffc`5b5e2651     KERNEL32!BaseThreadInitThunk+0x14
0b 0000001d`dcb1f810 00000000`00000000     ntdll!RtlUserThreadStart+0x21

fabiangreffrath commented 2 years ago

R_InterpolateTextureOffsets

Oh, wow! What could go wrong here?

rfomin commented 2 years ago

Here side_t *side = sides + s->affectee; affectee has garbage values, not sure.

rfomin commented 2 years ago

I guess we need to convert affectee to index and then to pointer etc. https://github.com/fabiangreffrath/woof/blob/347e430c7101040fbca5bced6e5ec892f0e1cd66/src/p_saveg.c#L2693

@fabiangreffrath Can't you reproduce it? Every save load crashes for me here with uncapped.

liPillON commented 2 years ago

the comment on dw brought me here

I've noticed that the ENDOOM screen is severly corrupted when exiting So I've checked the wad and the relative lump shows up in SLADE3 as graphic, not ansi text

removing the ENDOOM lump seems to prevent the game from crashing

rfomin commented 2 years ago

I've noticed that the ENDOOM screen is severly corrupted when exiting So I've checked the wad and the relative lump shows up in SLADE3 as graphic, not ansi text

removing the ENDOOM lump seems to prevent the game from crashing

But I can't find ENDOOM lump in stickney.wad

liPillON commented 2 years ago

I'm using the wad from the "StickneyE3V2.zip" linked in the wad's dw topic

rfomin commented 2 years ago

Right, "StickneyE3V2.zip" has broken ENDOOM lump.

fabiangreffrath commented 2 years ago

@fabiangreffrath Can't you reproduce it? Every save load crashes for me here with uncapped.

Yes, I have seen the crash meanwhile, though only very sporadically. Apparently, thinkers are recreated when a savegame is loaded. Strange that I have never encountered this when I tested my patch with a savegame of E2M4.

rfomin commented 2 years ago

This patch fixes it for me:

diff

```diff diff --git a/src/p_saveg.c b/src/p_saveg.c index c625369..d9a5e50 100644 --- a/src/p_saveg.c +++ b/src/p_saveg.c @@ -2574,6 +2574,8 @@ void P_UnArchiveSpecials (void) { byte tclass; + P_FreeSideScrollers(); + // read in saved thinkers while ((tclass = saveg_read8()) != tc_endspecials) // killough 2/14/98 switch (tclass) @@ -2693,6 +2695,7 @@ void P_UnArchiveSpecials (void) saveg_read_scroll_t(scroll); scroll->thinker.function.p1 = (actionf_p1)T_Scroll; P_AddThinker(&scroll->thinker); + P_AddSideScroller(scroll); break; } diff --git a/src/p_spec.c b/src/p_spec.c index c524ff6..722f316 100644 --- a/src/p_spec.c +++ b/src/p_spec.c @@ -2646,7 +2646,7 @@ void T_Scroll(scroll_t *s) static int maxsidescrollers, numsidescrollers; static scroll_t **sidescrollers; -static void P_AddSideScroller (scroll_t *s) +void P_AddSideScroller (scroll_t *s) { if (numsidescrollers == maxsidescrollers) { @@ -2656,7 +2656,7 @@ static void P_AddSideScroller (scroll_t *s) sidescrollers[numsidescrollers++] = s; } -static void P_FreeSideScrollers (void) +void P_FreeSideScrollers (void) { maxsidescrollers = 0; numsidescrollers = 0; diff --git a/src/p_spec.h b/src/p_spec.h index 96039d0..4fd4077 100644 --- a/src/p_spec.h +++ b/src/p_spec.h @@ -864,6 +864,10 @@ void T_Friction(friction_t *); // phares 3/12/98: friction thinker void T_Pusher(pusher_t *); // phares 3/20/98: Push thinker +void P_FreeSideScrollers(void); + +void P_AddSideScroller(scroll_t *s); + //////////////////////////////////////////////////////////////// // // Linedef and sector special handler prototypes ```

fabiangreffrath commented 2 years ago

This patch fixes it for me:

Perfect, please apply! 👍

fabiangreffrath commented 2 years ago

NB: Please add a check to only add type == sc_side scrollers!

NightFright2k19 commented 2 years ago

For clearification: I had actually already removed the ENDOOM gfx from this modified wad (together with adding a UMAPINFO for hiding ep.4 and GAMEINFO for GZDoom), without knowing it could trigger anything, it just didn't seem right to have a normal image instead of a text lump. That's why I added the pwad in its entirety without just linking to it.

Anyway, the crash would happen without it as well.

NightFright2k19 commented 2 years ago

Seems fixed with latest dev snapshot. Thanks, guys!

fabiangreffrath / woof

[Bug] Signal 11 crash with "Stickney Installation" #732