crash in ironwail after noclip

[j4reporting]

Win10, nvidia driver 546.17

this is a reproducible crash with ironwail 0.7 and git version 64c819f with -game bv (the brutalist volumes) ( save game attached) granted this did not happen during normal playthrough, only after noclip to check out something. vkquake does not crash.

1. load savegame
2. enable noclip
3. nopclip through the first door and the blue key door to the right ( there is a spawn behind the door)
4. kill the spawn
5. disable noclip, take the health pak
6. drop down and wait for the golden key to be lowered into lava and the scrag to appear.
7. kill the scrag
8. crash ( more scrags should spawn at this point )

event log entry ( ironwail 0.7.0 )

Faulting application name: ironwail.exe, version: 0.7.0.0, time stamp: 0x6414b4fe
Faulting module name: ironwail.exe, version: 0.7.0.0, time stamp: 0x6414b4fe
Exception code: 0xc0000005
Fault offset: 0x00000000000a5da1
Faulting process ID: 0x9358

Update: issue seems to be with the savegame. Can't reproduce with map bv3 instead of loading the savegame. savegame_bv3.zip

update2: crash triggers also during 'normal' play. sooner or later process bails out. not sure anymore, I suspect savegame was writen by vkquake, because I can't reproduce the crash with vkquake. If I use an older savegame ( savepoint at end of bv2) and proceed to next level bv3 (changelevel bv3 ) in ironwail everything is fine.
I guess this is the most likely explanation. I leave this open for now.

[andrei-drexler]

I can't seem to reproduce this crash with either a debug build or a release one (compiled with MSVC). Are you using mingw by any chance? If so, do you happen to also have Visual Studio installed, to see if this is compiler-specific? If not, I'm thinking I should probably tweak CI to retain build artifacts anyway.

[j4reporting]

Do you test with the original bv.zip release?
Bug is reproducible with the slightly newer bv1.01 (slipseer 1.1) release. Savegame written by ironwail with map from the original bv release. I know that updated maps can break savegames, like missplaced items and other things. This one is very sneaky, though. Still, does not seem to bother vkquake and quakespasm for some reason.

bv1.1
06.11.2023  06:35         8.237.960 bv3.bsp
04.11.2023  04:25         2.968.700 bv3.lit

sha256sum.exe bv3*
1d2cf1fc4e1edd8d35909df13b6237b19cb45d9acd625c46a84118acb33e8e47 *bv3.bsp
625f943d9832d0f281d1f1dbbc4d31194faffb9ba67700c265655927d53faa7b *bv3.lit

bv1.0
04.11.2023  04:25         8.237.844 bv3.bsp
04.11.2023  04:25         2.968.700 bv3.lit

sha256sum.exe bv3*
bccf502c4be745ba2577ad18fd34b42ff8964145902010aedfaabbe897762850 *bv3.bsp
625f943d9832d0f281d1f1dbbc4d31194faffb9ba67700c265655927d53faa7b *bv3.lit

ironwail.exe 0.7.0 is the github release ironwail git compiled with msvc 2022 (v.143 + latest win10 sdk ) a mingw build crashes too.

sdl2.dll is slightly newer 2.26.5 instead of 2.26.3 Otherwise all DLLs were extracted from the github release. And I use the older, bigger ironwail.pak ( qspasm conback )

change notes bv1.0 -> 1.01

1.01 - Small fixes

- fixed a misaligned texture
- added a center-print to explain Chthon fight
- added auto-saves to starts of all levels

[andrei-drexler]

Thanks, it looks like I was indeed testing v1.0. I can now reproduce the crash with v1.01, and at first blush it seems to be related to #242 (there's a null pointer access in SV_AreaTriggerEdicts).

[j4reporting]

this seems fix the crash when noclipping to the lower region, BUT I can still crash or lock-up the engine during normal play.
the easiest way to lock-up; load savegame, select GL or RL,, open the door, keep standing in front of the door and start shooting at the death knight in front of you. The third attack does not draw the grenade or rocket, and then it locks up pretty soon after that.

can't reproduce with vkquake and quakespasm

or try to clear the room behind the door. Sooner or later game either crashes or locks up.

[andrei-drexler]

Yup, things seemed ok initially (tried loading a whole buch of savefiles), but after further testing I noticed the lock ups as well. I'll have to take a closer look at the code.