GZDoom 4.7.1: Address not mapped to object (signal 11)

[louigi_verona]

Folks,

I can get gzdoom to reliably crash on a level. I was able to make it crash with monsters, but it doesn't seem to crash when no monsters are present. Additionally, I have previously played this level a lot on a different computer, using a much earlier version of gzdoom - and the crash did not occur.

The crash log:

Code: Select all

*** Fatal Error ***
Address not mapped to object (signal 11)
Address: 0x55d2b4d7f230

System: Linux louigi-ThinkPad-X1-Carbon-Gen-9 5.10.0-1057-oem #61-Ubuntu SMP Thu Jan 13 15:06:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

GZDoom version g4.7.1 (107ff702423686414680d6458fea63a2647692c4)
Command line: /opt/gzdoom/gzdoom -iwad Documents/Doom/DOOM2.WAD -warp 04 -file Documents/Doom/owads/pillage.wad
Wad 0: gzdoom.pk3
Wad 1: game_support.pk3
Wad 2: DOOM2.WAD
Wad 3: game_widescreen_gfx.pk3
Wad 4: pillage.wad

Current map: MAP04

viewx = 4984.037638
viewy = 5798.118843
viewz = 4.727447
viewangle = 145.371094

Executing: gdb --quiet --batch --command=gdb-respfile-zeypwK

I suspect the crash log might not be very useful here, but I hope the insight that I wasn't able to make the level crash without monsters is useful.

Also, I tried both Hardware Accelerated video mode and Doom Software Renderer, but there was no difference, the crash occurred regardless of video settings. I also tried switching between Vulkan and OpenGL, but the crash occurred.

I did read about a bug regarding monster corpses. Wondering if this might have something to do with it?

[louigi_verona]

I am now trying to test different versions. I tested the same map with version 4.7.0 and got the same crash with the same error. I will, however, note, that the error is fairly easily reproducible, but not always immediate. The crash happens in the very beginning of the level, but once I was able to beat the level with either 4.7.1 or 4.7.0 (I don't remember right now). However, I was then able to trigger the crash with both versions immediately.

Since I've played the same map on another laptop, I looked up the version on that older laptop and installed it. That version - 4.2.4 - so far works fine and I wasn't able to reproduce the crash.

Probably, the last thing to do to try to more or less exclude a possible driver/hardware problem is to try to install 4.7.1 on that other laptop (it runs Xubuntu 16.04) and see if I can reproduce the crash.

If there's anything I can do to offer a more helpful debug info, do let me know.

[_mental_]

Install gdb to get a callstack.

[louigi_verona]

No problem to install gdb, but what should I do next to get a callstack, or will it happen automatically?

[drfrag]

You need to run the executable thru gdb and type bt when it crashes. Run gdb followed by the name of the executable in order to do it, type run inside gdb then bt. That AFAIR i'm not a regular linux user.

[_mental_]

Run GZDoom as usual, and try to reproduce the crash again. Crash log should be extended with callstacks of all threads.

[drfrag]

Ah okay so it's automatic on linux it seems.

[louigi_verona]

Run GZDoom as usual, and try to reproduce the crash again. Crash log should be extended with callstacks of all threads.

Just checked. I had gdb installed all this time, but the crash log I posted in the original message was the only thing I got any time I got a crash.

[louigi_verona]

Folks, any suggestions? I do have gdb installed, but it did not create any extended callstacks.

[Chris]

I don't know why it's not making a stack trace if you have gdb installed. But alternatively if you have a more modern system with libdebuginfod1 and systemd-coredump installed and properly set up, then after a crash you can try running coredumpctl gdb. That should run gdb with the core dump of the last crashed application, and pull in the debug symbol packages for the libraries used. You can then run thread apply all bt full in gdb to get a full stack trace (which you can copy into a file and attach here, or put it in a code block in a spoiler).

[louigi_verona]

Is there an option to send someone who knows they can produce a callstack the map in question?

[drfrag]

Is it a public map or something you've developed yourself? Have you tried running "gdb ./gzdoom" and then "run -file pillage.wad" and "bt" inside gdb or something like that?
You'd need to take into account the path where the wads are of course, i see they are not in the same directory as gzdoom.

[louigi_verona]

It's a map generated by Oblige. I uploaded it here: https://louigiverona.com/files/var/pillage.wad

The problematic map is 04. The crash happens in the very first room, with lots of monsters and usually after you have killed a bunch of them.

[Guest]

I installed gdb and I got the extended crash message, how can I continue fixing the error?

Context: Same error, however it happens when I try to load a save on Pirate Doom.

[Joni]

It would seem that this problem has something to do with how swrenderer handles voxels. Some Googling reveals that similar problems pertaining to swrenderer have surfaced also in the past. At least for me switching to hardware rendering fixed the bug; or perhaps rather: works as a workaround.