Segfault on Ultimate Doom E2M2

[vanfanel]

HI there,

I have noticed there's a segfault crashing DoomRetro for me on GNU/Linux aarch64 in E2M2. It happens everytime I play, near an area with walls that go up and down.

(gdb) r
Starting program: /root/doom/dr -nosplash -iwad doomu.wad -pwad doom1music.wad
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ff7431140 (LWP 1570)]
[New Thread 0x7ff6b7b140 (LWP 1571)]
[New Thread 0x7ff4d58140 (LWP 1572)]
[New Thread 0x7fefead140 (LWP 1574)]

Thread 1 "dr" received signal SIGSEGV, Segmentation fault.
0x000000555564bb64 in R_DrawVisSpriteWithShadow (vis=0x555e133750) at r_things.c:547
547             if ((dc_numposts = column->numposts))
(gdb) bt
#0  0x000000555564bb64 in R_DrawVisSpriteWithShadow (vis=0x555e133750) at r_things.c:547
#1  0x000000555564f328 in R_DrawSprite (spr=0x555e133750) at r_things.c:1422
#2  0x000000555564f87c in R_DrawMasked () at r_things.c:1500
#3  0x00000055555b35d0 in R_RenderPlayerView () at r_main.c:1130
#4  0x00000055555e5244 in D_Display () at d_main.c:340
#5  0x00000055555e5800 in D_DoomLoop () at d_main.c:482
#6  0x00000055555eaad0 in D_DoomMain () at d_main.c:2636
#7  0x0000005555612e7c in main (argc=6, argv=0x7ffffff588) at doomretro.c:216
(gdb) p dc_numposts 
$1 = -1
(gdb) p column->numposts 
Cannot access memory at address 0x777676777482d1d0

Any idea on what could be happening here, @bradharding?

I am also attaching a savefile:

doomretro0_save.zip

[bradharding]

Hi @vanfanel. Thanks for the report. Are you building from the very latest source, or v4 9 released a couple of days ago?

[vanfanel]

@bradharding Both latest release and latest GIT code, it happens with both.

[bradharding]

Thanks. I'll look into it when I can.

[bradharding]

Hi @vanfanel. Home from work now! :) I'm not entirely sure why it caused the problem in the first place, but f1ea0e4f58b39290717465b3fe1600c6597f033f seems to fix it. Can you please test?

[vanfanel]

Tested. Sadly it's still happening, the same segfault when moving around that area.

[bradharding]

Not sure what's happening here just yet. The first time I ran your savegame, I was able to replicate the crash straight away, but haven't been able to since. I can only assume it's an issue with the patch code somewhere in r_patch.c, so I'm starting with that... EDIT: And so that's also assuming this isn't a regression with v4.9 and goes further back than that build...

[bradharding]

@vanfanel, when you have time, could you please test by disabling the r_randomstartframes CVAR and see if the crash still occurs?

EDIT: Also, please test by disabling the r_corpses_gib CVAR?

[vanfanel]

I disabled both (set them to off in dooretro.cfg) and the segfault still happens.

[bradharding]

Thanks. Tracking this one down is proving difficult. But I have just determined the bug was introduced in v4.0...

[bradharding]

The savegame you provided appears to have been saved when you had SMOOTHED.WAD loaded as well. This is why without SMOOTHED.WAD loaded, the savegame causes a crash. With SMOOTHED.WAD loaded, the savegame does not cause a crash.

[vanfanel]

The savegame you provided appears to have been saved when you had SMOOTHED.WAD loaded as well. This is why without SMOOTHED.WAD loaded, the savegame causes a crash. With SMOOTHED.WAD loaded, the savegame does not cause a crash.

Oh, sorry, I didn't know that the savegame had SMOOTHED.WAD data on it. However, I have the crash with and without SMOOTHER.WAD loaded. Do you mean that the crash shouldn't happen if I start a new game without SMOOTHED.WAD?

[bradharding]

I think I was getting distracted by a completely separate crash caused by not knowing that save being originally saved with SMOOTHED.WAD present.

As for the original crash, I haven't been able to effectively replicate it, except once. If starting a new game, with or without SMOOTHED.WAD loaded, going to that same place in E2M2, still causes the crash for you, I'll continue to look into it.

[jeffdoggett]

Won't help with this, but in my port I save the command line that was used to start the game in the savegame file after the EOF marker. So a quick look with an editor shows the info. Since the extra data is after the EOF marker, it is ignored when the game is loaded.

[bradharding]

Thanks @jeffdoggett. I think I will need to do something like that.

[bradharding]

Hi @vanfanel, I'm hoping 763735f98330bb5d5b4c66ecbe6529dd1974174e fixes this. Can you please test?

[vanfanel]

@bradharding Yes, sir! That made it, I can't reproduce the crash anymore! :+1:

[bradharding]

Ah! That's great! Thank you again for raising this issue, @vanfanel! It took a while, but I got there... :)

[vanfanel]

Thanks to you for your continued work on this great port! I have a lot of fun with it, and that has been the case for years now :)

[bradharding]

You're welcome! I thoroughly enjoy working on it, and I'm heading towards 10 years now.