Heretic: Random segfaults
kitchen-ace opened this issue · 14 comments
About once every 10-15 levels I get a random segfault that I can't reproduce. So far I've just been ignoring them. However playing E2M7 of htchest I seem to get them quite frequently (which may mean it's a different issue, but one that should be fixed if possible anyhow).
I made a debug release with -DCMAKE_BUILD_TYPE=Debug, I don't see it giving me any extra info though, just Segmentation fault (core dumped) like usual. Is there anything I can do to help figure out the cause?
Sigh.. I'm afraid it can be brought by swirling liquids. Could you please try this patch:
+++ /international-doom/src/heretic/r_swirl.c
@@ -108,14 +108,12 @@
byte *normalflat;
int i;
- normalflat = W_CacheLumpNum(flatnum, PU_STATIC);
+ normalflat = W_CacheLumpNum(flatnum, PU_LEVEL);
for (i = 0; i < FLATSIZE; i++)
{
distortedflat[i] = normalflat[offset[i]];
}
-
- W_ReleaseLumpNum(flatnum);
swirlflat = flatnum;
}
Yeah, something wrong with visplanes handling, most likely it's a swirling ones. Got this under Linux VM:
ead 1 "inter-heretic" received signal SIGSEGV, Segmentation fault.
0x000055555559a3dc in W_ReleaseLumpNum ()
(gdb) bt
#0 0x000055555559a3dc in W_ReleaseLumpNum ()
#1 0x00005555555e78b2 in R_DrawPlanes ()
#2 0x00005555555e6897 in R_RenderPlayerView ()
#3 0x000055555559ec40 in D_Display.part.0 ()
#4 0x000055555559ef21 in D_DoomLoop ()
#5 0x000055555559fb84 in D_DoomMain ()
#6 0x000055555556de6f in main ()
(gdb) q
A debugging session is active.
It's not enough just to use Debug build type, a debugger is also needed. In my case:
gdb --args ./inter-heretic -file htchest.wad from debug/src folder.
Could you please try this patch
This made it take longer to crash, but it still did. Will try running with gdb.
Slightly faster to run through levels not by using normal run, but by holding "go to next level". 😉
Thread 1 "inter-heretic" received signal SIGSEGV, Segmentation fault.
0x000055555559b91c in Z_ChangeTag2 (ptr=0x0, tag=8,
file=0x5555556277c0 "/home/gxx/Games/doom/src/international-doom/src/w_wad.c", line=499)
at /home/gxx/Games/doom/src/international-doom/src/z_zone.c:508
508 if (block->id != ZONEID)
(gdb) bt
#0 0x000055555559b91c in Z_ChangeTag2
(ptr=0x0, tag=8, file=0x5555556277c0 "/home/gxx/Games/doom/src/international-doom/src/w_wad.c", line=499)
at /home/gxx/Games/doom/src/international-doom/src/z_zone.c:508
#1 0x00005555555994cc in W_ReleaseLumpNum (lumpnum=2599)
at /home/gxx/Games/doom/src/international-doom/src/w_wad.c:499
#2 0x00005555555e24d8 in R_DrawPlanes ()
at /home/gxx/Games/doom/src/international-doom/src/heretic/r_plane.c:718
#3 0x00005555555e0ef3 in R_RenderPlayerView (player=0x555555732220 <players>)
at /home/gxx/Games/doom/src/international-doom/src/heretic/r_main.c:1167
#4 0x000055555559ddec in D_Display ()
at /home/gxx/Games/doom/src/international-doom/src/heretic/d_main.c:202
#5 0x000055555559e192 in D_DoomLoop ()
at /home/gxx/Games/doom/src/international-doom/src/heretic/d_main.c:394
#6 0x000055555559f1ad in D_DoomMain ()
at /home/gxx/Games/doom/src/international-doom/src/heretic/d_main.c:1420
#7 0x000055555556e069 in main (argc=3, argv=0x7fffffffe028)
at /home/gxx/Games/doom/src/international-doom/src/i_main.c:91
(gdb) q
A debugging session is active.
Slightly faster to run through levels not by using normal run, but by holding "go to next level".
It's not a crash at startup but one that happens midway through a level
That's true, but the crash itself happens once swirling liquid is appeared on the screen, and some levels have it right in starting view. Could you please revert my patch in r_swirl.c and this this instead, it's right in the end of file:
+++ international-doom/src/heretic/r_plane.c Fri Feb 9 22:20:02 2024
@@ -715,7 +715,7 @@
pl->bottom[x]);
if (!swirling)
- W_ReleaseLumpNum(lumpnum);
+ W_ReleaseLumpNum(firstflat + flattranslation[pl->picnum]);
}
}
}
I must say today I had a crash to desktop with the "Dungeons and Monsters" pwad. No error message or logs, the game just closed. Couldn't reproduce it, either. Was firing at an enemy with the Hellstaff near a lava river when it happened. I also have swirling liquids activated.
That's it, thank you too. Better I'll just use code from Doom, it is better polished there and slightly more compact. Fortunately, there is no need to care about possible "diff" in render code, so it can be modified as much as needed. Just need to spend some more time on testing, but looks likes everything will be fine soon.
I had once a non-reproducable crash like NightFright described with E2M4 from the vanilla campain. I have swirling liquids activated, but it happened as i walked into the glowing coal that does not swirl. But in this level is swirling lava. I am using triple or quad resolution with truecolor if that info is helpful, but i don't know anymore which was chosen as that happened.
Should be fixed now in #78. As far as I can understand this issue, by very simple words: engine was trying to free allocated memory of un-allocated lump (i.e. floor texture), which was leading to "segmentation fault", i.e. reading illegal memory addres. My second favorite thing to break after RAW screens breaking. 😩
Please just use git pull, I hope everything will be fine.
Just for the record: Would those crashes have happened (before your fix) if one had deactivated swirling flats, too?
Well I just went through E2M7 of htchest with no problems, so that's a good sign. Will close this for now. Other people should still comment if they get a crash.
Just for the record: Would those crashes have happened (before your fix) if one had deactivated swirling flats, too?
Not really. Crashes was introduced yesterday, with inaccurate changing of Crispy code. I have tried to make "diff" as small as possible, but in the end messed up critical things with memory handling.
🚨 Small important update for Hexen: save files extensions have been changed to ".sav", to be consistent with Doom and Heretic, and simply because they are no longer compatible with vanilla engine or Crispy (all games). The last save-breaking thing was done just now, it fixes small vanilla bug: when saving is performed while active lightning effect and then restored, "sectors with lighting" light levels becomes jammed to too bright. Now it's fixed, and it have to the last change in save game structure. Old ones ".hsx" files can be safely deleted, they will probably no longer work.
To be honest, i did not know that the Inter-saves are not compatible with the vanilla exe.
But the reason i did not know that was that i don't use the vanilla exe and so i did not test if the saves were backwards compatible. So it is totally ok for me.